尧图网站建设 
Supabase 怎么在 Postgres 中用 Vault 存储加密密钥并在 SQL 中引用【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase如果你的 API Key、服务凭证或连接地址不能以明文写进 SQL 函数、触发器或 Webhook 配置里Supabase Vault 提供了一条落地路径它是一个 Postgres 扩展加配套的 Dashboard 界面用于在数据库中以加密形式存储密钥类数据。密钥在磁盘上以认证加密基于libsodium的形式保存之后通过一个自动创建的 Postgres 视图在查询时解密因此你可以像查表一样在 SQL 中取用明文而备份和复制流里始终只有密文。适用对象是 Supabase 项目Dashboard 提供密钥管理界面密钥迁移一节涉及项目的根加密密钥通过 Management API 管理。Vault 也提供 Dashboard UI点击按钮、输入密钥、保存即可。本文主路径使用 SQL因为它是函数、触发器和 Webhook 中引用密钥时的同一套接口。用vault.create_secret()创建密钥在 SQL 编辑器中执行select vault.create_secret(my_s3kre3t);该函数返回新密钥的 UUID文档示例结果-[ RECORD 1 ]-------------------------------------- create_secret | c9b00867-ca8b-44fc-a81d-d20b8169be17密钥还可以带一个可选的、唯一的名称和一个可选描述作为vault.create_secret()的后续参数。名称用于之后在 SQL 中定位这条密钥select vault.create_secret(another_s3kre3t, unique_name, This is the description);文档示例返回结果-[ RECORD 1 ]----------------------------------------------------------------- id | 7095d222-efe5-4cd5-b5c6-5755b451e223 name | unique_name description | This is the description secret | 3mMeOcoG84a5F2uOfy2ugWYDp9sdxvCTmi6kTeT97bvA8rCEsG5DWWZtTU8VVeE key_id | nonce | \x9f2d60954ba5eb566445736e0760b0e3 created_at | 2022-12-14 02:34:23.8515900 updated_at | 2022-12-14 02:34:23.8515900可以看到返回记录中secret列是密文这就是落盘形态。给需要后续引用的密钥起名第二个参数是后续按名称取密钥的前提。验证落盘加密并从视图中读取明文查询vault.secrets表时看到的是加密后的数据。解密由自动创建的视图vault.decrypted_secrets完成它在查询时即时解密select * from vault.decrypted_secrets order by created_at desc limit 3;文档示例输出-[ RECORD 1 ]--------------------------------------------------------------------- id | 7095d222-efe5-4cd5-b5c6-5755b451e223 name | unique_name description | This is the description secret | 3mMeOcoG84a5F2uOfy2ugWYDp9sdxvCTmi6kTeT97bvA8rCEsG5DWWZtTU8VVeE decrypted_secret | another_s3kre3t key_id | nonce | \x9f2d60954ba5eb566445736e0760b0e3 created_at | 2022-12-14 02:34:23.8515900 updated_at | 2022-12-14 02:34:23.8515900判断成功的依据是视图中存在decrypted_secret列且内容与创建时写入的值一致同时secret列仍是密文。视图不落盘只在查询时运行所以磁盘、备份 dump 和复制流中密钥始终保持加密。文档同时强调任何能访问这个视图的角色都能拿到明文密钥所以要始终用 SQL 权限设置保护vault.decrypted_secrets的访问权限并谨慎考虑哪些角色可以访问vault.secrets表。在 SQL 中按名称引用密钥从 SQL 角度取密钥就是查询这个视图典型写法是按唯一名称过滤select decrypted_secret from vault.decrypted_secrets where name secret_key文档给出的一个实际用法是把它组合进 Webhook 请求头避免把密钥明文硬编码在 SQL 或 Webhook 配置中headers : jsonb_build_object( Content-Type, application/json, apikey, (select decrypted_secret from vault.decrypted_secrets where name secret_key) )Vault 文档说明这些密钥可以在数据库内的 Postgres 函数、触发器和 Webhook 中任意使用。automatic-embeddings 指南展示了另一个完整案例把项目 API URL 存进 Vault 并命名为project_url再由一个util.project_url()函数在运行时读取create function util.project_url() returns text language plpgsql security definer as $$ declare secret_value text; begin -- Retrieve the project URL from Vault select decrypted_secret into secret_value from vault.decrypted_secrets where name project_url; return secret_value; end; $$;创建该密钥时有两个环境分支来自同一指南按你的部署方式二选一本地 Supabase 栈写入supabase/seed.sqlselect vault.create_secret(http://api.supabase.internal:8000, project_url);云环境在 SQL 编辑器执行将project-url替换为你项目的 API URLselect vault.create_secret(project-url, project_url);更新密钥密钥失效或需要轮换时用vault.update_secret()更新。第一个参数是密钥的 UUID其后依次是新的密钥值、名称、描述select vault.update_secret( 7095d222-efe5-4cd5-b5c6-5755b451e223, n3w_updted_s3kret, updated_unique_name, This is the updated description );文档示例显示更新后再查视图decrypted_secret列已变为n3w_updted_s3kretupdated_at时间戳同步变化而created_at不变。根加密密钥的位置与跨项目迁移Vault 的加密密钥从不与加密数据一起存放在数据库里——即使攻击者拿到整个数据库的 dump也只能看到密文拿不到密钥本身。Supabase 为每个项目在后端创建并管理一个独立的根加密密钥并且你仍保有控制权Management API 的 pgsodium 配置端点会返回你项目 64 字符十六进制格式的根密钥可用于在 Supabase 之外解密数据或复制到另一个项目。对备份与恢复文档给出的边界是同一项目内的暂停与恢复、Point-in-Time 恢复或就地恢复保持同一把密钥密钥数据自动保持可读Restore to a new project 和 Branching 流程也会把密钥复制到新项目。但如果用手动pg_dump/pg_restore迁移到一个新项目新项目会生成自己的全新密钥无法解密从旧项目复制过来的密钥数据。在使用迁移后的数据之前必须先把旧项目的根密钥复制到新项目。pgsodiumManagement API 端点返回并接收 64 字符十六进制根密钥且仅对 active未暂停、未删除的项目可用export OLD_PROJECT_REFold_project_ref export NEW_PROJECT_REFnew_project_ref export SUPABASE_ACCESS_TOKENpersonal_access_token curl https://api.supabase.com/v1/projects/$OLD_PROJECT_REF/pgsodium \ -H Authorization: Bearer $SUPABASE_ACCESS_TOKEN | curl https://api.supabase.com/v1/projects/$NEW_PROJECT_REF/pgsodium \ -H Authorization: Bearer $SUPABASE_ACCESS_TOKEN \ -X PUT --json -其中old_project_ref、new_project_ref、personal_access_token是文档中标注的需要替换的值两个项目 ref 是项目 URL 中https://与.supabase.co之间的值令牌是 Personal Access Token。完整恢复流程见 Backup and restore using the CLI。与 pgsodium 的边界pgsodium 文档明确Supabase 不推荐继续使用 pgsodium它会进入弃用流程应改用 Vault。但两者是独立的扩展——Vault 不依赖 pgsodium也不受其弃用影响它共享同一套每项目根密钥相同格式、相同位置只是暴露自己的vault.secrets表和decrypted_secrets视图因此切到 Vault 不改变密钥管理方式。限制小结vault.decrypted_secrets视图可读即等于可读明文权限控制是这个方案的安全底线名称参数是唯一约束创建重名密钥不可行手动pg_dump迁移到新项目时未复制根密钥前密钥数据不可读且密钥管理端点只接受 active 状态的项目。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Supabase 怎么在 Postgres 中用 Vault 存储加密密钥并在 SQL 中引用？
Supabase 怎么在 Postgres 中用 Vault 存储加密密钥并在 SQL 中引用【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase如果你的 API Key、服务凭证或连接地址不能以明文写进 SQL 函数、触发器或 Webhook 配置里Supabase Vault 提供了一条落地路径它是一个 Postgres 扩展加配套的 Dashboard 界面用于在数据库中以加密形式存储密钥类数据。密钥在磁盘上以认证加密基于libsodium的形式保存之后通过一个自动创建的 Postgres 视图在查询时解密因此你可以像查表一样在 SQL 中取用明文而备份和复制流里始终只有密文。适用对象是 Supabase 项目Dashboard 提供密钥管理界面密钥迁移一节涉及项目的根加密密钥通过 Management API 管理。Vault 也提供 Dashboard UI点击按钮、输入密钥、保存即可。本文主路径使用 SQL因为它是函数、触发器和 Webhook 中引用密钥时的同一套接口。用vault.create_secret()创建密钥在 SQL 编辑器中执行select vault.create_secret(my_s3kre3t);该函数返回新密钥的 UUID文档示例结果-[ RECORD 1 ]-------------------------------------- create_secret | c9b00867-ca8b-44fc-a81d-d20b8169be17密钥还可以带一个可选的、唯一的名称和一个可选描述作为vault.create_secret()的后续参数。名称用于之后在 SQL 中定位这条密钥select vault.create_secret(another_s3kre3t, unique_name, This is the description);文档示例返回结果-[ RECORD 1 ]----------------------------------------------------------------- id | 7095d222-efe5-4cd5-b5c6-5755b451e223 name | unique_name description | This is the description secret | 3mMeOcoG84a5F2uOfy2ugWYDp9sdxvCTmi6kTeT97bvA8rCEsG5DWWZtTU8VVeE key_id | nonce | \x9f2d60954ba5eb566445736e0760b0e3 created_at | 2022-12-14 02:34:23.8515900 updated_at | 2022-12-14 02:34:23.8515900可以看到返回记录中secret列是密文这就是落盘形态。给需要后续引用的密钥起名第二个参数是后续按名称取密钥的前提。验证落盘加密并从视图中读取明文查询vault.secrets表时看到的是加密后的数据。解密由自动创建的视图vault.decrypted_secrets完成它在查询时即时解密select * from vault.decrypted_secrets order by created_at desc limit 3;文档示例输出-[ RECORD 1 ]--------------------------------------------------------------------- id | 7095d222-efe5-4cd5-b5c6-5755b451e223 name | unique_name description | This is the description secret | 3mMeOcoG84a5F2uOfy2ugWYDp9sdxvCTmi6kTeT97bvA8rCEsG5DWWZtTU8VVeE decrypted_secret | another_s3kre3t key_id | nonce | \x9f2d60954ba5eb566445736e0760b0e3 created_at | 2022-12-14 02:34:23.8515900 updated_at | 2022-12-14 02:34:23.8515900判断成功的依据是视图中存在decrypted_secret列且内容与创建时写入的值一致同时secret列仍是密文。视图不落盘只在查询时运行所以磁盘、备份 dump 和复制流中密钥始终保持加密。文档同时强调任何能访问这个视图的角色都能拿到明文密钥所以要始终用 SQL 权限设置保护vault.decrypted_secrets的访问权限并谨慎考虑哪些角色可以访问vault.secrets表。在 SQL 中按名称引用密钥从 SQL 角度取密钥就是查询这个视图典型写法是按唯一名称过滤select decrypted_secret from vault.decrypted_secrets where name secret_key文档给出的一个实际用法是把它组合进 Webhook 请求头避免把密钥明文硬编码在 SQL 或 Webhook 配置中headers : jsonb_build_object( Content-Type, application/json, apikey, (select decrypted_secret from vault.decrypted_secrets where name secret_key) )Vault 文档说明这些密钥可以在数据库内的 Postgres 函数、触发器和 Webhook 中任意使用。automatic-embeddings 指南展示了另一个完整案例把项目 API URL 存进 Vault 并命名为project_url再由一个util.project_url()函数在运行时读取create function util.project_url() returns text language plpgsql security definer as $$ declare secret_value text; begin -- Retrieve the project URL from Vault select decrypted_secret into secret_value from vault.decrypted_secrets where name project_url; return secret_value; end; $$;创建该密钥时有两个环境分支来自同一指南按你的部署方式二选一本地 Supabase 栈写入supabase/seed.sqlselect vault.create_secret(http://api.supabase.internal:8000, project_url);云环境在 SQL 编辑器执行将project-url替换为你项目的 API URLselect vault.create_secret(project-url, project_url);更新密钥密钥失效或需要轮换时用vault.update_secret()更新。第一个参数是密钥的 UUID其后依次是新的密钥值、名称、描述select vault.update_secret( 7095d222-efe5-4cd5-b5c6-5755b451e223, n3w_updted_s3kret, updated_unique_name, This is the updated description );文档示例显示更新后再查视图decrypted_secret列已变为n3w_updted_s3kretupdated_at时间戳同步变化而created_at不变。根加密密钥的位置与跨项目迁移Vault 的加密密钥从不与加密数据一起存放在数据库里——即使攻击者拿到整个数据库的 dump也只能看到密文拿不到密钥本身。Supabase 为每个项目在后端创建并管理一个独立的根加密密钥并且你仍保有控制权Management API 的 pgsodium 配置端点会返回你项目 64 字符十六进制格式的根密钥可用于在 Supabase 之外解密数据或复制到另一个项目。对备份与恢复文档给出的边界是同一项目内的暂停与恢复、Point-in-Time 恢复或就地恢复保持同一把密钥密钥数据自动保持可读Restore to a new project 和 Branching 流程也会把密钥复制到新项目。但如果用手动pg_dump/pg_restore迁移到一个新项目新项目会生成自己的全新密钥无法解密从旧项目复制过来的密钥数据。在使用迁移后的数据之前必须先把旧项目的根密钥复制到新项目。pgsodiumManagement API 端点返回并接收 64 字符十六进制根密钥且仅对 active未暂停、未删除的项目可用export OLD_PROJECT_REFold_project_ref export NEW_PROJECT_REFnew_project_ref export SUPABASE_ACCESS_TOKENpersonal_access_token curl https://api.supabase.com/v1/projects/$OLD_PROJECT_REF/pgsodium \ -H Authorization: Bearer $SUPABASE_ACCESS_TOKEN | curl https://api.supabase.com/v1/projects/$NEW_PROJECT_REF/pgsodium \ -H Authorization: Bearer $SUPABASE_ACCESS_TOKEN \ -X PUT --json -其中old_project_ref、new_project_ref、personal_access_token是文档中标注的需要替换的值两个项目 ref 是项目 URL 中https://与.supabase.co之间的值令牌是 Personal Access Token。完整恢复流程见 Backup and restore using the CLI。与 pgsodium 的边界pgsodium 文档明确Supabase 不推荐继续使用 pgsodium它会进入弃用流程应改用 Vault。但两者是独立的扩展——Vault 不依赖 pgsodium也不受其弃用影响它共享同一套每项目根密钥相同格式、相同位置只是暴露自己的vault.secrets表和decrypted_secrets视图因此切到 Vault 不改变密钥管理方式。限制小结vault.decrypted_secrets视图可读即等于可读明文权限控制是这个方案的安全底线名称参数是唯一约束创建重名密钥不可行手动pg_dump迁移到新项目时未复制根密钥前密钥数据不可读且密钥管理端点只接受 active 状态的项目。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考