aws privateca issuer
v1.4.0
AWS Private CA ist ein AWS-Dienst, der private CAs einrichten und verwalten sowie private Zertifikate ausstellen kann.
cert-manager ist ein Kubernetes-Add-on zur Automatisierung der Verwaltung und Ausstellung von TLS-Zertifikaten aus verschiedenen ausstellenden Quellen. Es stellt sicher, dass die Zertifikate gültig sind, wird regelmäßig aktualisiert und versucht, die Zertifikate rechtzeitig vor Ablauf zu erneuern.
Dieses Projekt fungiert als Add-on (siehe https://cert-manager.io/docs/configuration/external/) für cert-manager, das Zertifikatsanfragen mithilfe von AWS Private CA abzeichnet.
Installieren Sie zuerst den Cert-Manager (https://cert-manager.io/docs/installation/kubernetes/).
Installieren Sie dann AWS PCA Issuer mit Helm:
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-nameSie können die Diagrammkonfiguration in der Standardwertedatei überprüfen.
AWS PCA Issuer unterstützt ARM ab Version 1.3.0
Der AWS PCA-Aussteller verwaltet einen Test-ECR, der Versionen enthält, die jedem Commit im Hauptzweig entsprechen. Auf diese Bilder kann zugegriffen werden, indem das Bild-Repository auf public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test und das Bild-Tag auf latest gesetzt wird. Ein Beispiel dafür, wie dies geschieht, ist unten dargestellt:
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 Derzeit sind die einzigen konfigurierbaren Einstellungen der Zugriff auf AWS. Sie können also AWS_REGION , AWS_ACCESS_KEY_ID oder AWS_SECRET_ACCESS_KEY verwenden.
Alternativ können Sie mit den Feldern accessKeyIDSelector und secretAccessKeySelector in den Clusterissuer- und/oder Issuer-Manifesten beliebige Geheimnisse für den Zugriff und die geheimen Schlüssel angeben.
Der Zugriff auf AWS kann auch mithilfe einer EC2-Instanzrolle oder [IAM-Rollen für Servicekonten] (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) konfiguriert werden ).
Eine minimale Richtlinie zur Verwendung des Ausstellers mit einer Autorität würde wie folgt aussehen:
{
"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>"
}
]
}
Dieser Operator stellt zwei benutzerdefinierte Ressourcen bereit, die Sie verwenden können.
Beispiele finden Sie in den Beispiel- und Musterverzeichnissen.
Dies ist ein regulärer Namensraum-Aussteller, der als Referenz in Ihren Zertifikats-CRs verwendet werden kann.
Diese CR ist identisch mit dem AWSPCAIssuer. Der einzige Unterschied besteht darin, dass es keinen Namensraum hat und von überall aus referenziert werden kann.
Die Annotation cert-manager.io/cluster-issuer kann nicht verwendet werden, um auf einen AWSPCAClusterIssuer zu verweisen. Verwenden Sie stattdessen cert-manager.io/issuer: . Weitere Informationen finden Sie in dieser Ausgabe.
Der AWSPCA-Aussteller wartet vor der Signatur darauf, dass für CertificateRequests eine genehmigte Bedingung festgelegt ist. Wenn Sie eine ältere Version von cert-manager (vor v1.3) verwenden, können Sie diese Prüfung deaktivieren, indem Sie das Befehlszeilen-Flag -disable-approved-check für die Issuer-Bereitstellung angeben.
Der AWSPCA-Herausgeber drosselt die Anfragerate an den Kubernetes-API-Server standardmäßig auf 5 Abfragen pro Sekunde. Dies ist für neuere Versionen von Kubernetes, die API Priority und Fairness implementiert haben, nicht erforderlich. Wenn Sie eine neuere Version von Kubernetes verwenden, können Sie diese clientseitige Ratenbegrenzung deaktivieren, indem Sie das Befehlszeilenflag -disable-client-side-rate-limiting für die Issuer-Bereitstellung bereitstellen.
Bitte beachten Sie, dass dieses Plugin auf KIAM v4.0 getestet wurde, wenn Sie KIAM zur Authentifizierung verwenden. IRSA wird ebenfalls getestet und unterstützt.
Es gibt eine benutzerdefinierte AWS-Authentifizierungsmethode, die wir in unser Plugin codiert haben und die es einem Benutzer ermöglicht, ein Kubernetes-Geheimnis mit übergebenen AWS-Creds zu definieren, Beispiel hier. Der Benutzer wendet diese Datei mit seinen Creds an und verweist dann auf das Geheimnis in seinem Aussteller-CRD, wenn er das Plugin ausführt, Beispiel hier.
Das AWS Private Certificate Authority (PCA) Issuer Plugin unterstützt die folgenden Integrationen und Anwendungsfälle:
Integration mit Cert-Manager 1.4+ und entsprechenden Kubernetes-Versionen.
Authentifizierungsmethoden:
AWS Private CA-Funktionen:
Den Code für die Übersetzung finden Sie hier.
Abhängig davon, welche UsageTypes im Cert-Manager-Zertifikat festgelegt sind, werden unterschiedliche AWS PCA-Vorlagen verwendet. Diese Tabelle zeigt, wie die UsageTypes in die zu verwendende Vorlage übersetzt werden, wenn eine IssueCertificate-Anfrage gestellt wird:
| Cert-Manager-Nutzungstyp(en) | AWS PCA-Vorlagen-ARN |
|---|---|
| CodeSigning | acm-pca:::template/CodeSigningCertificate/V1 |
| ClientAuth | acm-pca:::template/EndEntityClientAuthCertificate/V1 |
| ServerAuth | acm-pca:::template/EndEntityServerAuthCertificate/V1 |
| OCSPSignierung | acm-pca:::template/OCSPSigningCertificate/V1 |
| ClientAuth, ServerAuth | acm-pca:::template/EndEntityCertificate/V1 |
| Alles andere | acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 |
Wenn Sie make test ausführen, wird der schriftliche Komponententest ausgeführt
Wenn Sie auf ein Problem stoßen wie
/home/linuxbrew/.linuxbrew/Cellar/go/1.17/libexec/src/net/cgo_linux.go:13:8: no such package located
Dies kann mit a behoben werden
brew install gcc@5
HINWEIS: Für die Durchführung dieser Tests fallen Gebühren in Ihrem AWS-Konto an .
Durch Ausführen von make e2etest werden die aktuellen Codeartefakte in ein Docker-Image umgewandelt, das auf einem Art Cluster ausgeführt wird und sicherstellt, dass die aktuelle Version des Codes weiterhin mit den unterstützten Workflows funktioniert
Der einfachste Weg, den Test zum Laufen zu bringen, wäre die Verwendung der folgenden Make-Ziele: make cluster && make install-eks-webhook && make e2etest
make cluster zum Laufen bringen make cluster erstellt eine Art Cluster auf Ihrem Computer, auf dem Cert-Manager sowie das Plugin „aws-pca-issuer“ installiert sind (unter Verwendung des HEAD des aktuellen Zweigs).
Bevor wir make cluster ausführen, müssen wir Folgendes tun:
- Halten Sie die folgenden Werkzeuge an Ihrer Maschine bereit:
- (Optional) Sie benötigen einen AWS IAM-Benutzer, um die Authentifizierung über K8-Geheimnisse zu testen. Sie können einen bereits vorhandenen Benutzer über export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name> für den Test bereitstellen. Diesem IAM-Benutzer sollte eine Richtlinie zugeordnet sein, die der in der Konfiguration aufgeführten Richtlinie folgt. Dieser Benutzer wird verwendet, um die Authentifizierung im Plugin über K8-Geheimnisse zu testen.
– Ein S3-Bucket mit deaktiviertem BPA in us-east-1. Nachdem Sie den Bucket erstellt haben, führen export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- Sie müssen AWS-Anmeldeinformationen in Ihr Terminal laden, die über die CLI mindestens die folgenden Aktionen über eine IAM-Richtlinie zulassen:
acm-pca:* : Dies dient dazu, dass private CAs zu Testzwecken über die entsprechenden APIs erstellt und gelöscht werden könneniam:CreatePolicy , iam:CreateUser und iam:AttachUserPolicyiam:CreateAccessKey und iam:DeleteAccessKey : Damit können wir Zugriffsschlüssel erstellen und löschen, um zu überprüfen, ob die Authentifizierung über K8-Geheimnisse funktioniert. Wenn der Benutzer über $PLUGIN_USER_NAME_OVERRIDE festgelegt wurdes3:PutObject und s3::PutObjectAcl können auf den oben erstellten S3-Bucket beschränkt werden – Ein AWS IAM OIDC-Anbieter. Legen Sie vor dem Erstellen des OIDC-Anbieters einen temporären Wert für $OIDC_IAM_ROLE fest ( export OIDC_IAM_ROLE=arn:aws:iam::000000000000:role/oidc-kind-cluster-role und führen Sie make cluster && make install-eks-webhook && make kind-cluster-delete ). Dies muss durchgeführt werden, andernfalls wird möglicherweise eine Fehlermeldung angezeigt, die sich über das Fehlen einer Datei .well-known/openid-configuration beschwert. Das Ausführen dieser Befehle hilft beim Bootstrap des S3-Buckets, sodass der OIDC-Anbieter erstellt werden kann. Legen Sie die Anbieter-URL des OIDC-Anbieters auf $OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster fest. Legen Sie die Zielgruppe auf sts.amazonaws.com fest.
– Eine IAM-Rolle, die eine Vertrauensbeziehung mit dem soeben erstellten IAM-OIDC-Anbieter hat. Eine Inline-Richtlinie für diese Rolle kann aus der Konfiguration abgerufen werden, außer dass Sie sie nicht auf eine bestimmte Zertifizierungsstelle beschränken können, da diese während des Testlaufs erstellt wird. Diese Rolle wird verwendet, um die Authentifizierung im Plugin über IRSA zu testen. Die Vertrauensbeziehung sollte etwa so aussehen:
{
"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"
}
}
}
]
}
Nachdem Sie diese Rolle erstellt haben, führen Sie export OIDC_IAM_ROLE=<IAM role arn you created above> aus
- make cluster den Cluster mit allen entsprechenden Umgebungsvariablen neu zu erstellen
- make install-eks-webhook installiert einen Webhook in diesem Cluster, der die Verwendung von IRSA ermöglicht
– make e2etest führt einen End-to-End-Test für die Art Cluster durch, die über make cluster erstellt wurde.
– Nachdem Sie den Controller-Code lokal aktualisiert haben, besteht eine einfache Möglichkeit, den neuen Controller-Code erneut bereitzustellen und den End-to-End-Test erneut auszuführen, darin, Folgendes auszuführen: make upgrade-local && make e2etest
IRSA dazu zu bringen, an Kind zu arbeiten, wurde stark durch den folgenden Blog inspiriert: https://reece.tech/posts/oidc-k8s-to-aws/
Wenn Sie außerdem testen möchten, ob kontoübergreifende Aussteller funktionieren, benötigen Sie Folgendes:
– Ein separates AWS-Konto mit einer Rolle, die dem Anrufer vertraut, der den End-to-End-Test über die CLI startet. Für die Rolle ist eine Richtlinie mit den folgenden Berechtigungen erforderlich
acm-pca:* : Dies dient dazu, dass der Test eine private Zertifizierungsstelle für das andere Konto erstellen kannram:GetResourceShareAssociations , ram:CreateResourceShare und ram:DeleteResourceShare : Diese ermöglichen die Erstellung einer Zertifizierungsstelle, die mit dem Quellkonto (Aufrufer) geteilt werden kannexport PLUGIN_CROSS_ACCOUNT_ROLE=<name of the role you created above> ausführen. Wenn Sie dies nicht tun, wird eine Meldung angezeigt, dass kontoübergreifende Tests übersprungen werden, da diese Umgebungsvariable nicht festgelegt ist.Bald sollten diese Tests automatisch für jeden PR ausgeführt werden, aber vorerst wird jeder PR einen Kernmitarbeiter für das Projekt haben, der die Tests manuell durchführt, um sicherzustellen, dass es bei den unterstützten Arbeitsabläufen zu keinen Rückschritten kommt
Die Tests sind ziemlich einfach, sie benötigen eine Reihe von „Ausstellervorlagen“ (Basisname für einen AWS-PCA-Aussteller sowie eine AWSIssuerSpec) und eine Reihe von „Zertifikatvorlagen“ (Basisname für den Zertifikatstyp usw.). eine Zertifikatsspezifikation). Die Tests nehmen dann jede Zertifikatsspezifikation und wenden sie auf jede Ausstellerspezifikation an. Durch den Test wird sichergestellt, dass alle anhand der Emittentenspezifikationen erstellten Aussteller einen Bereitschaftsstatus erreichen und dass jedes von einem Aussteller ausgestellte Zertifikat einen Bereitschaftsstatus erreicht. Es wurde überprüft, dass die Aussteller mit den verschiedenen Zertifikaten sowohl für Cluster- als auch für Namespace-Aussteller funktionieren.
Die End-to-End-Aktualisierung umfasst größtenteils die Aktualisierung dieser „Ausstellerspezifikationen“ und „Zertifikatsspezifikationen“, die sich in e2e/e2e_test.go befinden. Wenn der Test darüber hinaus aktualisiert werden muss, ist die Kernlogik für den Test auch in e2e/e2e_test.go eingebettet. Bei den anderen Dateien im E2e-Ordner handelt es sich hauptsächlich um Dienstprogramme, die nicht häufig aktualisiert werden sollten
Testen Sie, um sicherzustellen, dass der im Blog „End-to-End-TLS-Verschlüsselung auf Amazon EKS mit dem neuen AWS Load Balancer Controller einrichten“ beschriebene Workflow funktioniert. So führen Sie den Test aus: make cluster && make install-eks-webhook && make blog-test
Test, der die neueste Version über Helm herunterlädt, überprüft, ob das Plugin korrekt und mit der richtigen Version installiert wurde, und dann korrekt gelöscht wird. Um den Test auszuführen make cluster && make install-eks-webhook && make helm-test
Überprüfen Sie das Geheimnis mit den AWS-Anmeldeinformationen: Die Werte AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY müssen Base64-codiert sein.
Wenn die generierte CertificateRequest keine Ereignisse anzeigt, ist es sehr wahrscheinlich, dass Sie eine ältere Version von cert-manager verwenden, die keine Genehmigungsprüfung unterstützt. Deaktivieren Sie die Genehmigungsprüfung bei der Ausstellerbereitstellung.
Wenn Sie Hilfe benötigen, ziehen Sie bitte die folgenden Veranstaltungsorte in Betracht (in der Reihenfolge):
Wir freuen uns über Community-Beiträge und Pull-Requests.
Weitere Informationen zum Melden von Problemen, zum Einrichten einer Entwicklungsumgebung und zum Einreichen von Code finden Sie in unserem Beitragsleitfaden.
Wir halten uns an den Amazon Open Source Verhaltenskodex.
