Il semble que le problème provienne d’un souci de permissions associé à l’utilisation du certificat ACM dans l’Ingress.
Pourrais-je voir les politiques (policies) de l’utilisateur ou du rôle qui fait appel au certificat ? Normalement, le rôle EKS doit inclure des permissions spécifiques pour ACM dans sa politique pour accéder au certificat. Sans ces permissions, aucun accès n’est accordé par défaut sur AWS.
Il serait utile de tester et de vérifier en attribuant temporairement des droits étendus à EKS pour observer le résultat, puis d’affiner les permissions ensuite.
Voici un exemple de politique qui pourrait être utilisé :
# Exemple à ajouter en plus de l'existant au sein du rôle utilisé par EKS
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"acm:DescribeCertificate",
"acm:ListCertificates",
"acm:GetCertificate"
],
"Resource": "*"
}
]
}
Quelques infos supplémentaires, je ne t’ai pas indiqué comment retrouver le rôle utilisé par EKS
Connecte-toi à la console AWS et navigue jusqu’au service EKS.
Ensuite, dans le tableau de bord EKS, sélectionne le cluster qui t’intéresse. Une fois dans la section des détails du cluster, tu devrais trouver l’information relative au rôle IAM utilisé par le cluster.
Cette information est généralement disponible sous la section “Configuration” ou “Details”.
Dans le doute, J’ai également donné le “AWSCertificateManagerReadOnly” au role du Node Group.
Mais j’ai toujours la même erreur
Warning FailedDeployModel 11s (x3 over 20s) ingress (combined from similar events): Failed deploy model due to AccessDenied: Access denied to certificate ‘arn:aws:acm:eu-west-3:203271543287:certificate/19fdb8cd-f089-4c68-9bcb-*********’
status code: 403, request id: 8966a6c7-5896-4176-8301-a1eb11b85516
J’ai trouvé quasiment aucune info à ce sujet sur Internet …
Après avoir creusé un peu et grâce à cloudtrail, je pense avoir trouvé d’ou vient le problème :
“eventTime”: “2024-02-07T11:52:06Z”,
“eventSource”: “kms.amazonaws.com”,
“eventName”: “CreateGrant”,
“awsRegion”: “eu-west-3”,
“sourceIPAddress”: “acm.amazonaws.com”,
“userAgent”: “acm.amazonaws.com”,
“errorCode”: “AccessDenied”,
“errorMessage”: “User: arn:aws:sts::2032715xxxxx:assumed-role/role_eks_lb/170730360166xxxx is not authorized to perform: kms:CreateGrant on resource: arn:aws:kms:eu-west-3:203271xxxx:key/a6cb187b-955f-495b-axxxxxxxx with an explicit deny in a service control policy”
Le rôle “role_eks_lb” n’a pas les droits sur la clé géré par KMS pour le certificat.
Le problème c’est que cette clé a été généré automatiquement par AWS lors de la création du certificat et la policy n’est pas modifiable.
Je trouve ton retour très intéressant et pertinent ! À ce sujet, pourrais-tu vérifier quelque chose dans le service AWS KMS ? Tu peux te rendre dans la section “cmk” (customer managed key) et vérifier si des clés ont été générées.
Je suspecte qu’il ne s’agit pas d’une clé gérée par AWS, car sinon, tu n’aurais pas reçu de message “denied”.
Cependant, j’ai précédemment mis en place une restriction concernant la création des clés KMS. Cette restriction stipule que les clés ne peuvent être explicitement créées que par l’utilisateur original “student”. Et ce user “student” original ne peut pas être supprimé.
Le problème majeur dont j’ai du faire face est lié à l’utilisation des CMK par les apprenants. Ils spécifiaient parfois un rôle ou un utilisateur qui était ensuite supprimé. En conséquence, la clé devient “non manageable” parce que le propriétaire initial de la clé n’existe plus.
Je préfère t’épargner la procédure compliquée imposée par Amazon pour supprimer ces clées.
Dans le contexte de KMS, le compte AWS n’est pas implicitement le propriétaire de la ressource. Cela signifie que même le compte “root” ne peut pas supprimer ou modifier la clé si le compte n’est pas spécifié dans la key policy comme ceci :
{
"Version": "2012-10-17",
"Id": "key-default-1",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root" # Ligne obligatoire a ajouter lors de la création qui donne le droit au "compte de gérer la clef"
},
"Action": "kms:*",
"Resource": "*"
},
Si tu souhaites absoluement passer par CMK et ACM je peux voir pour débloquer ça, mais je préfèrerais largement que tu passes par un certbot.
Tu pourras cependant normalement gérer les droits CMK et ajouter l’action “creategrant” depuis le user “student” mais je te propose vivement d’ajouter le principal plus haut également en 2ème policy.
Il y a une bien une CMK sur le compte mais c’est moi qui l’ai créé à des fins de test, j’ai d’ailleurs demandé sa suppression mais avec la politique AWS, il faut attendre 7 jours …
Cependant la clé lié au certificat est bien une clé Managé par AWS :
Description : Default key that protects my ACM private keys when no other key is defined
Et sa date de création correspond bien à la première fois que j’ai généré un certificat via ACM, et il n’y avait pas de CMK sur le compte auparavant.
D’après la Doc ACM il s’agit du comportement par défaut, si pas de clé présente, AWS crée une clé “aws/acm” par défaut.
Je crois que je vais laisser tomber ACM et passer sur du let’s encrypt.
Dans ce cas, il doit y avoir une relation implicite lors de la création entre l’ALB et ACM, comme c’est l’ALB qui va appeller le certificat. Je vais essayer de creuser pourquoi EKS à besoin de “grant” sur ACM, car normalement lui se positionne en tant que client
