aws privateca issuer
v1.4.0
AWS プライベート CA は、プライベート CA を設定および管理し、プライベート証明書を発行できる AWS のサービスです。
cert-manager は、さまざまな発行元からの TLS 証明書の管理と発行を自動化する Kubernetes アドオンです。証明書が有効であることを確認し、定期的に更新し、有効期限が切れる前の適切な時期に証明書の更新を試みます。
このプロジェクトは、AWS プライベート CA を使用して証明書リクエストをサインオフする cert-manager のアドオン (https://cert-manager.io/docs/configuration/external/ を参照) として機能します。
まず 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 発行者はバージョン 1.3.0 以降で ARM をサポートします
AWS PCA 発行者は、メイン ブランチの各コミットに対応するバージョンを含むテスト 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を使用できます。
あるいは、clusterissuer および/または issuer マニフェストのaccessKeyIDSelectorフィールドとsecretAccessKeySelectorフィールドを使用して、アクセス キーと秘密キーの任意のシークレットを指定できます。
AWS へのアクセスは、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>"
}
]
}
このオペレーターは、使用できる 2 つのカスタム リソースを提供します。
例は、example ディレクトリとサンプル ディレクトリにあります。
これは、証明書 CR で参照として使用できる通常の名前空間発行者です。
この CR は AWSPCAIssuer と同一です。唯一の違いは、名前空間がなく、どこからでも参照できることです。
cert-manager.io/cluster-issuerアノテーションを使用してAWSPCAClusterIssuerを指すことはできません。代わりに、 cert-manager.io/issuer:を使用してください。詳細については、この号を参照してください。
AWSPCA 発行者は、署名する前に、CertificateRequest に承認された条件が設定されるまで待機します。古いバージョンの cert-manager (v1.3 より前) を使用している場合は、コマンド ライン フラグ-disable-approved-check発行者のデプロイメントに指定することで、このチェックを無効にすることができます。
AWSPCA 発行者は、デフォルトで kubernetes API サーバーへのリクエストの速度を 1 秒あたり 5 クエリに抑制します。これは、API の優先度と公平性を実装した新しいバージョンの Kubernetes では必要ありません。新しいバージョンの Kubernetes を使用している場合は、発行者のデプロイメントにコマンド ライン フラグ-disable-client-side-rate-limiting指定することで、このクライアント側のレート制限を無効にできます。
認証に KIAM を使用している場合、このプラグインは KIAM v4.0 でテストされていることに注意してください。 IRSA もテストされ、サポートされています。
プラグインにコード化したカスタム AWS 認証方法があり、ユーザーは AWS 認証を渡されて Kubernetes シークレットを定義できます (例はこちら)。ユーザーはそのファイルを自分の認証情報とともに適用し、プラグインの実行時に発行者 CRD 内のシークレットを参照します (ここに例を示します)。
AWS プライベート認証局 (PCA) 発行者プラグインは、次の統合とユースケースをサポートしています。
cert-manager 1.4 以降および対応する Kubernetes バージョンとの統合。
認証方法:
AWS プライベート CA の機能:
翻訳のコードはここにあります。
Cert-Manager 証明書にどのUsageTypesが設定されているかに応じて、異なるAWS PCAテンプレートが使用されます。次の表は、IssueCertificate リクエストを行うときに、UsageType がどのテンプレートに変換されて使用されるかを示しています。
| Cert-Manager の使用タイプ | AWS PCA テンプレート ARN |
|---|---|
| コードサイニング | acm-pca:::template/CodeSigningCertificate/V1 |
| クライアント認証 | acm-pca:::template/EndEntityClientAuthCertificate/V1 |
| サーバー認証 | acm-pca:::template/EndEntityServerAuthCertificate/V1 |
| OCSP署名 | acm-pca:::template/OCSPSigningCertificate/V1 |
| クライアント認証、サーバー認証 | acm-pca:::template/EndEntityCertificate/V1 |
| その他すべて | acm-pca:::template/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 プラグインがインストールされているマシン上に kind クラスターを作成します (現在のブランチの HEAD を使用)
make cluster実行する前に、次のことを行う必要があります。
- マシンに次のツールが必要です。
- (オプション) K8 シークレットによる認証をテストするには、AWS IAM ユーザーが必要です。 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>実行します。
- CLI 経由で、IAM ポリシー経由で最低限次のアクションを許可する AWS 認証情報を端末にロードする必要があります。
acm-pca:* : これは、テスト用に適切な API を介してプライベート CA を作成および削除できるようにするためです。iam:CreatePolicy 、 iam:CreateUser 、およびiam:AttachUserPolicyの権限が必要です。iam: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実行します) 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 IRSA の使用を可能にするその種類のクラスターに Webhook をインストールします。
- make e2etest make clusterによって作成された種類のクラスターに対してエンドツーエンドのテストを実行します。
- コントローラー コードをローカルで更新した後、新しいコントローラー コードを再デプロイしてエンドツーエンド テストを再実行する簡単な方法は、:: make upgrade-local && make e2etest実行することです。
IRSA に Kind を導入するにあたっては、次のブログから大きな影響を受けました: https://reece.tech/posts/oidc-k8s-to-aws/
クロスアカウント発行者が機能しているかどうかもテストしたい場合は、以下が必要になります。
- CLI 経由でエンドツーエンド テストを開始する呼び出し元を信頼するロールを持つ別の AWS アカウント。ロールには次の権限を持つポリシーが必要です。
acm-pca:* : これは、テストで他のアカウントであるプライベート CA を作成できるようにするためです。ram:GetResourceShareAssociations 、 ram:CreateResourceShare 、およびram:DeleteResourceShare : これらにより、ソース (呼び出し元) アカウントと共有できる CA の作成が可能になります。export 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 でエンコードされている必要があります。
生成された CertificateRequest にイベントが表示されない場合は、承認チェックをサポートしていない古いバージョンの cert-manager を使用している可能性があります。発行者の導入時に承認チェックを無効にします。
サポートが必要な場合は、次の会場を (順番に) ご検討ください。
コミュニティへの貢献やプル リクエストを歓迎します。
問題の報告、開発環境のセットアップ、コードの送信方法の詳細については、貢献ガイドを参照してください。
私たちは Amazon オープンソースの行動規範を遵守します。
