aws privateca issuer
v1.4.0
AWS Private CA 是一项 AWS 服务，可以设置和管理私有 CA，以及颁发私有证书。
cert-manager 是一个 Kubernetes 插件，用于自动管理和颁发来自各种颁发源的 TLS 证书。它将确保证书有效、定期更新，并尝试在到期前的适当时间更新证书。
该项目充当 cert-manager 的插件（请参阅 https://cert-manager.io/docs/configuration/external/），使用 AWS Private CA 签署证书请求。
首先安装 cert-manager (https://cert-manager.io/docs/installation/kubernetes/)。
然后使用 Helm 安装 AWS PCA Issuer：
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-name您可以检查默认值文件中的图表配置。
AWS PCA Issuer 从版本 1.3.0 开始支持 ARM
AWS PCA Issuer 维护一个测试 ECR，其中包含与主分支上的每个提交相对应的版本。可以通过将图像存储库设置为public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test并将图像标签设置为latest来访问这些图像。下面显示了如何完成此操作的示例：
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-name
--set image.repository=public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test
--set image.tag=latest截至目前，唯一可配置的设置是访问 AWS。因此，您可以使用AWS_REGION 、 AWS_ACCESS_KEY_ID或AWS_SECRET_ACCESS_KEY 。
或者，您可以使用集群颁发者和/或颁发者清单中的accessKeyIDSelector和secretAccessKeySelector字段为访问密钥和秘密密钥提供任意机密。
还可以使用 EC2 实例角色或 [服务账户的 IAM 角色] (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html ）。
使用具有权威的发行人的最低政策如下所示：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "awspcaissuer",
"Action": [
"acm-pca:DescribeCertificateAuthority",
"acm-pca:GetCertificate",
"acm-pca:IssueCertificate"
],
"Effect": "Allow",
"Resource": "arn:aws:acm-pca:<region>:<account_id>:certificate-authority/<resource_id>"
}
]
}
该运算符提供了两个可供您使用的自定义资源。
示例可以在示例和示例目录中找到。
这是一个常规命名空间颁发者，可以用作证书 CR 中的引用。
此 CR 与 AWSPCAIssuer 相同。唯一的区别是它没有命名空间，可以从任何地方引用。
cert-manager.io/cluster-issuer注释不能用于指向AWSPCAClusterIssuer 。相反，请使用cert-manager.io/issuer: 。请参阅此问题以获取更多信息。
AWSPCA 颁发者将等待证书请求在签名之前设置已批准的条件。如果使用旧版本的 cert-manager（v1.3 之前），您可以通过向颁发者部署提供命令行标志-disable-approved-check来禁用此检查。
默认情况下，AWSPCA 发行者将对 kubernetes API 服务器的请求速率限制为每秒 5 个查询。对于已实现 API 优先级和公平性的较新版本的 Kubernetes 来说，这不是必需的。如果使用较新版本的 Kubernetes，您可以通过向颁发者部署提供命令行标志-disable-client-side-rate-limiting来禁用此客户端速率限制。
请注意，如果您使用 KIAM 进行身份验证，则该插件已在 KIAM v4.0 上进行了测试。 IRSA 也经过测试和支持。
我们在插件中编写了一种自定义 AWS 身份验证方法，允许用户使用传入的 AWS Creds 定义 Kubernetes 密钥，示例如下。用户使用其信用应用该文件，然后在运行插件时引用其发行者 CRD 中的秘密，示例如下。
AWS 私有证书颁发机构 (PCA) 颁发者插件支持以下集成和用例：
与 cert-manager 1.4+ 和相应的 Kubernetes 版本集成。
认证方式：
AWS 私有 CA 功能：
翻译代码可以在这里找到。
根据 Cert-Manager 证书中设置的UsageType，将使用不同的 AWS PCA 模板。下表显示了在发出 IssueCertificate 请求时如何将UsageTypes 转换为要使用的模板：
| 证书管理器使用类型 | AWS PCA 模板 ARN |
|---|---|
| 代码签名 | acm-pca:::模板/CodeSigningCertificate/V1 |
| 客户端验证 | acm-pca:::模板/EndEntityClientAuthCertificate/V1 |
| 服务器验证 | acm-pca:::模板/EndEntityServerAuthCertificate/V1 |
| OCSP签名 | acm-pca:::模板/OCSPSigningCertificate/V1 |
| 客户端验证、服务器验证 | acm-pca:::模板/EndEntityCertificate/V1 |
| 其他一切 | acm-pca:::模板/BlankEndEntityCertificate_CSRPassthrough/V1 |
运行make test将运行编写的单元测试
如果您遇到类似问题
/home/linuxbrew/.linuxbrew/Cellar/go/1.17/libexec/src/net/cgo_linux.go:13:8: no such package located
这可以通过修复
brew install gcc@5
注意：运行这些测试将会在您的 AWS 账户中产生费用。
运行make e2etest将获取当前代码工件并将其转换为将在同类集群上运行的 Docker 映像，并确保当前版本的代码仍然适用于支持的工作流程
运行测试的最简单方法是使用以下 make 目标： make cluster && make install-eks-webhook && make e2etest
make cluster运行make cluster将在安装了 Cert-Manager 以及 aws-pca-issuer 插件的计算机上创建一个集群（使用当前分支的 HEAD）
在运行make cluster之前，我们需要执行以下操作：
- 您的机器上有以下工具：
- （可选）您将需要 AWS IAM 用户来通过 K8 密钥测试身份验证。您可以通过export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name>将现有用户提供到测试中。该 IAM 用户应附加一个策略，该策略遵循配置中列出的策略。该用户将用于通过 K8 密钥在插件中测试身份验证。
- us-east-1 中禁用 BPA 的 S3 存储桶。创建存储桶后，运行export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- 您需要将 AWS 凭证加载到您的终端中，通过 CLI，该凭证至少允许通过 IAM 策略执行以下操作：
acm-pca:* ：这样可以通过适当的 API 创建和删除私有 CA 以进行测试iam:CreatePolicy 、 iam:CreateUser和iam:AttachUserPolicyiam:CreateAccessKey和iam:DeleteAccessKey ：这允许我们创建和删除用于验证通过 K8 密钥进行的身份验证是否有效的访问密钥。如果用户是通过 $PLUGIN_USER_NAME_OVERRIDE 设置的s3:PutObject和s3::PutObjectAcl这些的范围可以缩小到您上面创建的 s3 存储桶- AWS IAM OIDC 提供商。在创建 OIDC 提供程序之前，为 $OIDC_IAM_ROLE 设置临时值 ( export OIDC_IAM_ROLE=arn:aws:iam::000000000000:role/oidc-kind-cluster-role并运行make cluster && make install-eks-webhook && make kind-cluster-delete ）。这需要完成，否则您可能会看到一条错误，抱怨缺少文件 .well-known/openid-configuration。运行这些命令有助于引导 S3 存储桶，以便创建 OIDC 提供程序。将 OIDC 提供商的提供商 URL 设置为$OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster 。将受众设置为sts.amazonaws.com 。
- 与刚刚创建的 IAM OIDC 提供商具有信任关系的 IAM 角色。可以从配置中获取此角色的内联策略，但您无法将其范围限制到特定 CA，因为这些策略将在测试运行期间创建。该角色将用于通过 IRSA 测试插件中的身份验证。信任关系应该类似于：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "${OIDC_ARN}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"${OIDC_URL}:sub": "system:serviceaccount:aws-privateca-issuer:aws-privateca-issuer-sa"
}
}
}
]
}
创建此角色后，运行export OIDC_IAM_ROLE=<IAM role arn you created above>
- 使用所有适当的环境变量集make cluster重新创建集群
- make install-eks-webhook将在该类型的集群中安装一个 webhook，以启用 IRSA
- make e2etest将针对通过make cluster创建的种类集群运行端到端测试。
- 在本地更新控制器代码后，重新部署新控制器代码并重新运行端到端测试的一个简单方法是运行:: make upgrade-local && make e2etest
让 IRSA 在 Kind 上工作深受以下博客的启发：https://reece.tech/posts/oidc-k8s-to-aws/
如果您还想测试跨账户发卡机构是否正常工作，您将需要：
- 一个单独的 AWS 账户，其角色信任通过 CLI 启动端到端测试的调用者，该角色将需要具有以下权限的策略
acm-pca:* ：这样测试就可以为其他帐户创建私有 CAram:GetResourceShareAssociations 、 ram:CreateResourceShare和ram:DeleteResourceShare ：这些允许创建可与源（调用者）帐户共享的 CAexport PLUGIN_CROSS_ACCOUNT_ROLE=<name of the role you created above> 。如果您不这样做，您将看到一条有关由于未设置此环境变量而跳过跨帐户测试的消息。很快这些测试应该会在每个 PR 上自动运行，但目前每个 PR 都将有一个项目核心协作者手动运行测试，以确保支持的工作流程不会出现退化
测试相当简单，他们将采用一组“颁发者模板”（aws-pca-issuer 的基本名称以及 AWSIssuerSpec）和一组“证书模板”（证书类型的基本名称以及证书规格）。然后，测试将获取每个证书规范并将其应用于每个颁发者规范。该测试将确保根据颁发者规范制作的所有颁发者都达到就绪状态，并确保颁发者颁发的每个证书都达到就绪状态。具有不同证书的颁发者经验证适用于集群和命名空间颁发者。
在大多数情况下，端到端更新将更新这些位于 e2e/e2e_test.go 中的“发行者规范”和“证书规范”。如果测试需要更新，测试的核心逻辑也嵌入在 e2e/e2e_test.go 中。 e2e 文件夹中的其他文件主要是不需要频繁更新的实用程序
进行测试以确保博客使用新的 AWS 负载均衡器控制器在 Amazon EKS 上设置端到端 TLS 加密中列出的工作流程正常运行。运行测试： make cluster && make install-eks-webhook && make blog-test
测试通过 Helm 拉取最新版本，检查插件是否正确安装，版本正确，然后正确删除。运行测试make cluster && make install-eks-webhook && make helm-test
使用 AWS 凭证检查密钥：AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 值必须采用 Base64 编码。
如果生成的证书请求未显示任何事件，则您很可能使用的是不支持批准检查的旧版本的证书管理器。在发行人部署中禁用批准检查。
如需帮助，请考虑以下地点（按顺序）：
我们欢迎社区贡献和拉取请求。
有关如何报告问题、设置开发环境和提交代码的更多信息，请参阅我们的贡献指南。
我们遵守亚马逊开源行为准则。
