aws privateca issuer
v1.4.0
AWS Private CA est un service AWS qui peut configurer et gérer des autorités de certification privées, ainsi qu'émettre des certificats privés.
cert-manager est un module complémentaire Kubernetes permettant d'automatiser la gestion et l'émission de certificats TLS à partir de diverses sources émettrices. Il garantira que les certificats sont valides, mis à jour périodiquement et tentera de renouveler les certificats à un moment approprié avant leur expiration.
Ce projet agit comme un module complémentaire (voir https://cert-manager.io/docs/configuration/external/) au cert-manager qui approuve les demandes de certificat à l'aide d'AWS Private CA.
Installez d'abord cert-manager (https://cert-manager.io/docs/installation/kubernetes/).
Installez ensuite AWS PCA Issuer à l'aide de Helm :
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-nameVous pouvez vérifier la configuration du graphique dans le fichier de valeurs par défaut.
L'émetteur AWS PCA prend en charge ARM à partir de la version 1.3.0
L'émetteur AWS PCA gère un ECR de test qui contient des versions correspondant à chaque validation sur la branche principale. Ces images sont accessibles en définissant le référentiel d'images sur public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test et la balise d'image sur latest . Un exemple de la façon dont cela est effectué est présenté ci-dessous :
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 Pour l'instant, les seuls paramètres configurables sont l'accès à AWS. Vous pouvez donc utiliser AWS_REGION , AWS_ACCESS_KEY_ID ou AWS_SECRET_ACCESS_KEY .
Vous pouvez également fournir des secrets arbitraires pour les clés d'accès et secrètes avec les champs accessKeyIDSelector et secretAccessKeySelector dans les manifestes du clusterissuer et/ou de l'émetteur.
L'accès à AWS peut également être configuré à l'aide d'un rôle d'instance EC2 ou de [Rôles IAM pour les comptes de service] (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html ).
Une politique minimale visant à utiliser l'émetteur avec une autorité ressemblerait à ce qui suit :
{
"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>"
}
]
}
Cet opérateur fournit deux ressources personnalisées que vous pouvez utiliser.
Des exemples peuvent être trouvés dans les répertoires d'exemples et d'échantillons.
Il s'agit d'un émetteur à espace de noms standard qui peut être utilisé comme référence dans vos CR de certificat.
Ce CR est identique à AWSPCAIssuer. La seule différence est qu'il n'est pas doté d'un espace de noms et peut être référencé de n'importe où.
L'annotation cert-manager.io/cluster-issuer ne peut pas être utilisée pour pointer vers un AWSPCAClusterIssuer . Utilisez plutôt cert-manager.io/issuer: . Veuillez consulter ce problème pour plus d'informations.
L'émetteur AWSPCA attendra que les CertificateRequests aient une condition approuvée définie avant de signer. Si vous utilisez une ancienne version de cert-manager (avant la v1.3), vous pouvez désactiver cette vérification en fournissant l'indicateur de ligne de commande -disable-approved-check au déploiement de l'émetteur.
L'émetteur AWSPCA limitera le taux de requêtes adressées au serveur API Kubernetes à 5 requêtes par seconde par défaut. Cela n'est pas nécessaire pour les versions plus récentes de Kubernetes qui ont implémenté la priorité et l'équité de l'API. Si vous utilisez une version plus récente de Kubernetes, vous pouvez désactiver cette limitation de débit côté client en fournissant l'indicateur de ligne de commande -disable-client-side-rate-limiting au déploiement de l'émetteur.
Veuillez noter que si vous utilisez KIAM pour l'authentification, ce plugin a été testé sur KIAM v4.0. IRSA est également testé et pris en charge.
Il existe une méthode d'authentification AWS personnalisée que nous avons codée dans notre plugin qui permet à un utilisateur de définir un secret Kubernetes avec les crédits AWS transmis, exemple ici. L'utilisateur applique ce fichier avec ses informations d'identification, puis référence le secret dans son CRD d'émetteur lors de l'exécution du plugin, exemple ici.
Le plug-in émetteur AWS Private Certificate Authority (PCA) prend en charge les intégrations et les cas d'utilisation suivants :
Intégration avec cert-manager 1.4+ et les versions Kubernetes correspondantes.
Méthodes d'authentification :
Fonctionnalités de l'autorité de certification privée AWS :
Le code de la traduction peut être trouvé ici.
En fonction des UsageTypes définis dans le certificat Cert-Manager, différents modèles AWS PCA seront utilisés. Ce tableau montre comment les UsageTypes sont traduits en modèle à utiliser lors d'une demande IssueCertificate :
| Type(s) d'utilisation de Cert-Manager | ARN du modèle AWS PCA |
|---|---|
| Signature de code | acm-pca :::template/CodeSigningCertificate/V1 |
| ClientAuth | acm-pca :::template/EndEntityClientAuthCertificate/V1 |
| Authentification du serveur | acm-pca :::template/EndEntityServerAuthCertificate/V1 |
| OCSPSignature | acm-pca :::template/OCSPSigningCertificate/V1 |
| AuthClient, AuthServeur | acm-pca :::template/EndEntityCertificate/V1 |
| Tout le reste | acm-pca :::template/BlankEndEntityCertificate_CSRPassthrough/V1 |
L'exécution make test exécutera le test unitaire écrit
Si vous rencontrez un problème comme
/home/linuxbrew/.linuxbrew/Cellar/go/1.17/libexec/src/net/cgo_linux.go:13:8: no such package located
Cela peut être résolu avec un
brew install gcc@5
REMARQUE : L'exécution de ces tests entraînera des frais sur votre compte AWS .
L'exécution de make e2etest prendra les artefacts de code actuels et les transformera en une image Docker qui s'exécutera sur un type de cluster et garantira que la version actuelle du code fonctionne toujours avec les workflows pris en charge.
Le moyen le plus simple d'exécuter le test serait d'utiliser les cibles make suivantes : make cluster && make install-eks-webhook && make e2etest
make cluster make cluster créera un type de cluster sur votre machine sur lequel Cert-Manager est installé ainsi que le plugin aws-pca-issuer (en utilisant le HEAD de la branche actuelle)
Avant d'exécuter make cluster nous devrons procéder comme suit :
- Ayez les outils suivants sur votre machine :
- (Facultatif) Vous aurez besoin d'un utilisateur AWS IAM pour tester l'authentification via les secrets K8. Vous pouvez fournir un utilisateur déjà existant dans le test via export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name> . Cet utilisateur IAM doit être associé à une stratégie qui suit la stratégie répertoriée dans Configuration. Cet utilisateur servira à tester l'authentification dans le plugin via les secrets K8.
- Un bucket S3 avec BPA désactivé dans us-east-1. Après avoir créé le bucket, exécutez export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- Vous aurez besoin d'informations d'identification AWS chargées dans votre terminal qui, via la CLI, autorisent au minimum les actions suivantes via une stratégie IAM :
acm-pca:* : Ceci permet de créer et de supprimer des autorités de certification privées via les API appropriées à des fins de test.iam:CreatePolicy , iam:CreateUser et iam:AttachUserPolicyiam:CreateAccessKey et iam:DeleteAccessKey : Cela nous permet de créer et de supprimer des clés d'accès à utiliser pour valider que l'authentification via les secrets K8 est fonctionnelle. Si l'utilisateur a été défini via $PLUGIN_USER_NAME_OVERRIDEs3:PutObject et s3::PutObjectAcl peuvent être étendus au compartiment s3 que vous avez créé ci-dessus - Un fournisseur AWS IAM OIDC. Avant de créer le fournisseur OIDC, définissez une valeur temporaire pour $OIDC_IAM_ROLE ( export OIDC_IAM_ROLE=arn:aws:iam::000000000000:role/oidc-kind-cluster-role et exécutez make cluster && make install-eks-webhook && make kind-cluster-delete ). Cela doit être fait, sinon vous pourriez voir une erreur se plaignant de l'absence d'un fichier .well-known/openid-configuration. L'exécution de ces commandes permet d'amorcer le compartiment S3 afin que le fournisseur OIDC puisse être créé. Définissez l'URL du fournisseur OIDC sur $OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster . Définissez l'audience sur sts.amazonaws.com .
- Un rôle IAM qui a une relation de confiance avec le fournisseur IAM OIDC qui vient d'être créé. Une stratégie en ligne pour ce rôle peut être récupérée à partir de la configuration, sauf que vous ne pouvez pas l'étendre à une autorité de certification particulière, car celles-ci seront créées lors de l'exécution du test. Ce rôle servira à tester l'authentification dans le plugin via IRSA. La relation de confiance devrait ressembler à ceci :
{
"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"
}
}
}
]
}
Après avoir créé ce rôle, exécutez export OIDC_IAM_ROLE=<IAM role arn you created above>
- make cluster recrée le cluster avec toutes les variables d'environnement appropriées définies
- make install-eks-webhook installera un webhook dans ce type de cluster qui permettra l'utilisation d'IRSA
- make e2etest exécutera un test de bout en bout sur le type de cluster créé via make cluster .
- Après avoir mis à jour le code du contrôleur localement, un moyen simple de redéployer le nouveau code du contrôleur et de réexécuter le test de bout en bout consiste à exécuter :: make upgrade-local && make e2etest
Faire fonctionner l'IRSA sur Kind a été fortement inspiré par le blog suivant : https://reece.tech/posts/oidc-k8s-to-aws/
Si vous souhaitez également tester que les émetteurs multi-comptes fonctionnent, vous aurez besoin de :
- Un compte AWS distinct qui a un rôle qui fait confiance à l'appelant qui lance le test de bout en bout via la CLI, le rôle aura besoin d'une stratégie avec les autorisations suivantes
acm-pca:* : C'est pour que le test puisse créer une autorité de certification privée pour l'autre compteram:GetResourceShareAssociations , ram:CreateResourceShare et ram:DeleteResourceShare : Ceux-ci permettent la création d'une autorité de certification pouvant être partagée avec le compte source (appelant).export PLUGIN_CROSS_ACCOUNT_ROLE=<name of the role you created above> . Si vous ne le faites pas, vous verrez un message indiquant que les tests multi-comptes sont ignorés car cette variable d'environnement n'est pas définie.Bientôt, ces tests devraient être exécutés automatiquement sur chaque PR, mais pour le moment, chaque PR aura un collaborateur principal du projet qui exécutera les tests manuellement pour garantir l'absence de régression sur les flux de travail pris en charge.
Les tests sont assez simples, ils prendront un ensemble de « modèles d'émetteur » (nom de base pour un aws-pca-issuer ainsi qu'un AWSIssuerSpec) et un ensemble de « modèles de certificat » (nom de base pour le type de certificat ainsi que une spécification de certificat). Les tests prendront ensuite chaque spécification de certificat et l'appliqueront à chaque spécification d'émetteur. Le test garantira que tous les émetteurs issus des spécifications de l'émetteur atteignent un état prêt et garantira que chaque certificat émis par un émetteur atteint un état prêt. Il est vérifié que les émetteurs avec les différents certificats fonctionnent à la fois pour les émetteurs de cluster et d'espace de noms.
Pour l'essentiel, la mise à jour de bout en bout consistera à mettre à jour ces « spécifications de l'émetteur » et « spécifications du certificat » qui résident dans e2e/e2e_test.go. Si le test doit être mis à jour au-delà de cela, la logique de base du test est également intégrée dans e2e/e2e_test.go. Les autres fichiers du dossier e2e sont principalement des utilitaires qui ne devraient pas nécessiter de mises à jour fréquentes.
Testez pour vous assurer que le flux de travail présenté dans le blog Configuration du chiffrement TLS de bout en bout sur Amazon EKS avec le nouveau contrôleur AWS Load Balancer est fonctionnel. Pour exécuter le test : make cluster && make install-eks-webhook && make blog-test
Test qui extrait la dernière version via Helm, vérifie que le plugin a été correctement installé, avec la bonne version, puis est correctement supprimé. Pour exécuter le test, make cluster && make install-eks-webhook && make helm-test
Vérifiez le secret avec les informations d'identification AWS : les valeurs AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY doivent être codées en base64.
Si le CertificateRequest généré ne montre aucun événement, il est très probable que vous utilisez une ancienne version de cert-manager qui ne prend pas en charge le contrôle d'approbation. Désactivez le contrôle d’approbation lors du déploiement de l’émetteur.
Pour obtenir de l’aide, veuillez considérer les sites suivants (dans l’ordre) :
Nous apprécions les contributions de la communauté et les demandes de tirage.
Consultez notre guide de contribution pour plus d’informations sur la façon de signaler des problèmes, de configurer un environnement de développement et de soumettre du code.
Nous adhérons au code de conduite Amazon Open Source.
