Table of Contents
Kubernetes AWS cross-account domain validation for SSL domains using cert-manager
Let's say you have a k8s cluster deployed in AWS in account A. You also have a different account, B and you wish to use a domain with ssl certificates from account B to point to a load balancer of the k8s cluster in account A.
First you need a user in account B that will be used by the cert-manager pods in k8s in account A and that user needs the following policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "route53:GetChange",
"Resource": "arn:aws:route53:::change/*"
},
{
"Effect": "Allow",
"Action": [
"route53:ChangeResourceRecordSets",
"route53:ListResourceRecordSets"
],
"Resource": "arn:aws:route53:::hostedzone/*"
},
{
"Effect": "Allow",
"Action": "route53:ListHostedZonesByName",
"Resource": "*"
}
]
}
cert-manager needs the AWS access keys so create those for this user.
Now create a user and attach this policy to it.
On your account A create a role with policy that allows that role to assume the role of account B (policy above). Example:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": "arn:aws:iam::<account-id-of-role-B>:role/<role-name>",
"Action": "sts:AssumeRole"
}
]
}
In “Trust relationship” tab enter which entities can assume this role. This will vary on your k8s setup. If using OIDC, you can use something like
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<account-A-id>:oidc-provider/oidc.eks.eu-central-1.amazonaws.com/id/<oidc-id>"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.eu-central-1.amazonaws.com/id/<oidc-id>:sub": "system:serviceaccount:<cert-manager-namespace>:<cert-manager-svc-acc-name>"
}
}
}
]
}
If you have EKS pod identity agent running in your cluster, your pods can assume this role like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
Also in account A, you need to associate the created role with the pods in the cluster that will use it. Go to your cluster and add an association in Access > Pod Identity associations tab in EKS. Enter the role that you created, the namespace where the cert-manager pods are and the service account to use.
The cert-manager pods should now be able to create the Letsencrypt TXT record in the DNS zone of account B.
Tested on
- 2025.02