2023-21: 我的 1Password 密钥管理实践

这期周报分享我的 1Password 密钥管理实践，主要内容包括常见的密码管理，SSH/Shell 集成和 CI/CD 应用。

这些实践应当同样适用于 bitwarden 等服务。

密码管理

常见的 SaaS 服务密码管理直接使用 1Password 跨平台客户端创建即可，我个人会遵循如下原则：

每个网站都使用随机生成的唯一密码

1Password 默认使用 Smart Password 来根据网站的要求来生成，不满意的话可以自行微调，比如生成 32 位带大小写字母，数字和符号的密码。

两步验证应开尽开

两步验证是保护账号安全十分有效的手段，如果网站本身支持，应当尽可能开启。

我个人更喜欢 TOTP (Time-based one-time password) 而不是基于短信的两步验证方案：

TOTP 是纯离线计算，不需要等待接收短信，速度更快
TOTP 能够更好的与登陆流程集成，比如 1Password 会在登陆成功后自动复制 code, 部分支持的网站中还会直接自动填充，体验更顺畅
TOTP 不依赖手机，在手机不在身边或者遗失时也能正常工作

1Password 的浏览器插件集成了 Scan QR Code 功能，在开启两步验证时直接扫码即可。

密保问题和答案也是密码

现在还需要设置密保问题和答案的服务已经不多了，但是如果需要设置的话，请将他们视作密码的一部分：不要使用真实的回答，将问题原文记录下来，并使用密码生成器生成随机字符串作为答案。

SSH 集成

1Password 在上一轮融资之后大刀阔斧地开发了一系列开发者工具，SSH 集成就是其中之一。

对我来说，它能解决如下问题：

本地无需再存储 SSH Secret Key，避免了密钥泄漏，也避免了被恶意软件读取的可能
在机器出现故障或者需要迁移时，不需要考虑密钥同步，避免了密钥丢失
所有对 SSH Key 的访问都需要经过 1Password 显式的弹窗请求，从而避免恶意软件在后台静默访问

它的思路非常简单：开发一个 SSH Agent，对外暴露为 SSH_AUTH_SOCK，这样所有 SSH Key 请求都由本地 1Password 客户端来处理。

配置完成后，所有应用首次访问指定的 SSH Key 都会弹出如下窗口：

该窗口会展示应用 X 尝试访问 SSH Key Y，只有在认证通过后才能正常获取到 key 的内容。根据各自系统的配置不同，支持 Apple Touch ID，Windows Hello 等生物验证，在 Linux 平台上还提供了完整的 polkit 和 PAM 支持，会调用系统内置的用户认证机制提供原生体验。

配置 SSH Agent

使用这个功能首先需要正确配置 1Password SSH Agent。

在 1Password 客户端的配置中勾选并开启 SSH Agent：

在 ssh config 增加如下配置以指定 IdentityAgent：

Host *
  IdentityAgent ~/.1password/agent.sock

根据实际的情况，可以对不同的 Host 增加一些额外配置，比如指定 Host 不使用 1Password：

Host ec2-server
  HostName 1.2.3.4
  User ec2-user
  IdentityFile ~/.ssh/ssh-key-not-on-1password.pem
  IdentityAgent none

或者为其指定一个 key：

Host github.com
    User git
    IdentitiesOnly yes
    IdentityFile ~/.ssh/github.pub

最后设置 SSH_AUTH_SOCK 即可：

export SSH_AUTH_SOCK=~/.1password/agent.sock

迁移 SSH Key

完成 SSH 配置之后，我们就可以开始迁移自己的 SSH Key 了。目前 1Password 支持 Ed25519 和 RSA (2048-bit, 3072-bit, and 4096-bit) 两种 key，点击 New Item，选择 SSH Key，然后将 Private Key 添加进去就行。Private Key 添加完毕后 1Password 会自动生成一系列信息以供区分（体验满分！）：

配置完毕后可以使用 git fetch 等命令来验证～

Shell 集成

除了 SSH 集成之外，1Password 还基于他们的 CLI 开发了 shell-plugins。它解决的问题与 SSH 集成是类似的：很多开发者本地电脑上都以静态方式存储着 AWS/GCP/Github 等服务的密钥，万一泄漏的话可能就会导致测试环境甚至生产环境受到影响。思路同样非常简单，1Password 负责存储实际的密钥，而 1Password Plugin 是一层简单的 wrapper，将 GITHUB_TOKEN 等环境变量替换为实际的密钥，然后再调用对应的命令。

以 Github Plugin 为例，本地的 op/plugins.sh 内容如下：

export OP_PLUGIN_ALIASES_SOURCED=1
alias gh="op plugin run -- gh"

而对应的具体实现为：

func GitHubCLI() schema.Executable {
    return schema.Executable{
        Name:    "GitHub CLI",
        Runs:    []string{"gh"},
        DocsURL: sdk.URL("https://cli.github.com"),
        NeedsAuth: needsauth.IfAll(
            needsauth.NotForHelpOrVersion(),
            needsauth.NotWithoutArgs(),
        ),
        Uses: []schema.CredentialUsage{
            {
                Name: credname.PersonalAccessToken,
            },
        },
    }
}

配置 Shell 集成同样十分简单：

# Signin op to make sure op itself works
op signin
# Setup plugin gh
op plugin init gh

所有的 shell plugin 都开源在 shell-plugins，使用 Golang 开发，如果有想支持的命令行工具欢迎提交 PR！

CI/CD 应用

最后想分享的是 1Password 在 CI/CD 中的应用。Github Actions 提供了内置的 Secrets 功能，但是有如下问题：

Secrets 要求 Admin 权限，但是有时候项目的维护者可能只有 Committer 权限（比如 ASF 项目增加修改 Secrets 都需要向 Infra 团队提交工单）
Secrets 只能 per repo 或者 per org 配置，在跨多个 repo 写作时配置复杂且麻烦
Secrets 只能在 Github 平台中使用，无法支撑本地开发和调试等场景

OpenDAL 项目就遇到了这些问题：

OpenDAL 中大量服务需要配置 Secrets，其中部分 Secrets 还需要进行周期轮换，通过 ASF Infra 团队来修改不仅等待时间长，而且大幅度增加了对方的工作量
OpenDAL 的 Committer 调试服务时同样依赖 Secrets，但是很难保证 Secrets 在传递过程中的安全和同步

为此，OpenDAL 团队采用了基于 1Password 的密钥管理方案。

申请 1Password 开源赞助

感谢 1Password 对开源项目的大力支持，只需要向 1password-teams-open-source 提交 PR 即可获取免费的 1Password Teams membership。OpenDAL 提交的 PR 参见：Add Apache OpenDAL (incubating)。OpenDAL 创建了一个独立的 Services Vault 并将权限赋予给所有的 PPMC 和 Committers，这样确保了团队内部对所有 Secrets 访问的一致性，消除了对 @Xuanwo 的单点依赖。

设置 1Password Services Account

在最近的更新中，1Password 增加了 Service Account 功能，支持授权该账户访问特定的 Vault。我们向 Infra team 提交了开通 1Password/load-secrets-action 并设置 OP_SERVICE_ACCOUNT_TOKEN 的申请。到这里，我们的 Github 环境已经可以正常从 CI 中获取 1Password 存储的密钥了。

配置 Github Actions

接下来我们只需要使用 load-secrets-action 来加载密钥即可，以 OpenDAL 配置 COS 服务为例：

- name: Load secret
  id: op-load-secret
  uses: 1password/load-secrets-action@v1
  with:
    export-env: true
  env:
    OP_SERVICE_ACCOUNT_TOKEN: $
    OPENDAL_COS_TEST: op://services/cos/test
    OPENDAL_COS_BUCKET: op://services/cos/bucket
    OPENDAL_COS_ENDPOINT: op://services/cos/endpoint
    OPENDAL_COS_SECRET_ID: op://services/cos/secret_id
    OPENDAL_COS_SECRET_KEY: op://services/cos/secret_key

- name: Test
  shell: bash
  working-directory: core
  run: cargo test cos -- --show-output
  env:
    RUST_BACKTRACE: full
    RUST_LOG: debug

export-env 表示将这些密钥导出为环境变量
OP_SERVICE_ACCOUNT_TOKEN 是我们之前配置好的 service account token
op://services/cos/test 表示使用 services vault 的 cos 条目中的 test 字段值来替换

需要注意的是，该方案同样依赖静态的 OP_SERVICE_ACCOUNT_TOKEN 密钥，如果泄漏可能导致整个 vault 中的密钥泄漏，所以：

如果场景不是像 OpenDAL 这样的复杂，请使用 configure-aws-credentials 和 google-github-actions/auth 等 actions 实现基于 GitHub OIDC 的无密钥认证
所有配置进入 Vault 的密钥需遵循最小化原则，能且只能访问指定资源，比如 AWS 资源需配置 IAM 子账户并通过 role 限制权限

总结

本文分享了我在日常工作和生活中使用 1Password 的实践经验，希望能对大家设计自己的密钥管理方案提供一些借鉴！

May 27, 2023, 3:11 p.m.

漩涡的周报