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 編碼。
如果產生的憑證要求未顯示任何事件，則您很可能使用的是不支援已核准檢查的舊版的憑證管理員。在發行人部署中停用批准檢查。
如需協助，請考慮以下地點（依序）：
我們歡迎社區貢獻和拉取請求。
有關如何報告問題、設定開發環境和提交程式碼的更多信息，請參閱我們的貢獻指南。
我們遵守亞馬遜開源行為準則。
