本文为 SPIRE 官方文档 plugin_server_upstreamauthority_awssecret 的中文译本,以英文原文为准。
🔗 穿越源码分析:Server 详解 · UpstreamAuthority · 上游 CA 与无缝轮换

服务端插件:UpstreamAuthority "awssecret"

awssecret 插件从 AWS SecretsManager 加载根 CA 凭据,用它们为 server 的签名权威(signing authority)生成中间签名证书(intermediate signing certificate)。这些中间证书是针对由 ServerCA 插件生成的 CSR 签发(mint)的。

该插件接受以下配置项:

配置项	说明
region	AWS Secrets Manager 所在的 AWS 区域(Region)
cert_file_arn	用于签名的 "上游" CA 证书的 ARN。如果包含多条证书,它们会按出现顺序加入证书链,其中第一条证书为用于签名的那条。
key_file_arn	"上游" CA 密钥文件的 ARN
bundle_file_arn	要纳入信任包(trust bundle)的根证书的 ARN。如果 `cert_file_arn` 包含一条自签名(self-signed)根 CA 证书,则此字段可以不设置。否则,`bundle_file_arn` 必须包含一条或多条根 CA 证书
access_key_id	AWS access key ID
secret_access_key	AWS secret access key
secret_token	AWS secret token
assume_role_arn	要担任(assume)的角色的 ARN

只有 region、cert_file_arn 和 key_file_arn 必须配置。你可以根据所选择的方式(即如何让 SPIRE Server 访问这些 ARN)来可选地配置其余字段。

如果 SPIRE Server 这样访问 ARN	则以下额外字段为必填
通过提供 access key id 与 secret access key	`access_key_id`、`secret_access_key`
通过使用某个 IAM 账号的临时凭据(注意: 每次 server 启动时提供一个新的有效 token 是 server 用户的责任)	`access_key_id`、`secret_access_key`、`secret_token`
通过一个附加了对这些 ARN 具备读取权限角色的 EC2 实例	无
通过将 UpstreamAuthority 插件配置为担任另一个对这些 secret 具备访问权限的 IAM 角色(注意: 提供 access key id 与 secret access key 的那个 IAM 用户必须具备担任该另一 IAM 角色的权限,或者附加在 EC2 实例上的角色必须具备此能力。)	`access_key_id`、`secret_access_key`、`secret_token`、`assume_role_arn`

由于插件仅在启动时从 AWS secrets manager 拉取 secret,因此不建议对 secret 启用自动轮换。

SPIRE Server 要求你为 CA 证书和 CA 密钥分别使用不同的 Amazon Resource Name(ARN)。

关于 AWS Secrets Manager 的更多信息,见 AWS Secrets Manager 文档。

一份配置示例:

hcl

    UpstreamAuthority "awssecret" {
        plugin_data {
            region = "us-west-2",
            cert_file_arn = "cert",
            key_file_arn = "key",
            bundle_file_arn = "bundle",
            access_key_id = "ACCESS_KEY_ID",
            secret_access_key = "SECRET_ACCESS_KEY",
            secret_token = "SECRET_TOKEN"
            assume_role_arn = "role"
        }
    }

服务端插件:UpstreamAuthority "awssecret" ​

服务端插件:UpstreamAuthority "awssecret"