From 613a2fa6360c5db7b366ebf9a4eb4caa8aaede0f Mon Sep 17 00:00:00 2001 From: Richard Wall Date: Tue, 8 Oct 2024 19:50:58 +0100 Subject: [PATCH] Format the numbered list items Signed-off-by: Richard Wall --- .../docs/configuration/acme/dns01/route53.md | 343 ++++++++++-------- 1 file changed, 189 insertions(+), 154 deletions(-) diff --git a/content/docs/configuration/acme/dns01/route53.md b/content/docs/configuration/acme/dns01/route53.md index 65d9028a2b..91e10047ff 100644 --- a/content/docs/configuration/acme/dns01/route53.md +++ b/content/docs/configuration/acme/dns01/route53.md @@ -138,7 +138,22 @@ If you deploy cert-manager on EKS, [Pod Identity](https://docs.aws.amazon.com/ek It is a three step process: 1. [Setup the EKS Pod Identity agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) in your cluster, then 2. [Assign an IAM role to the cert-manager Kubernetes service account](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html). -3. Restart the cert-manager Deployment so that the EKS Pod Identity Agent can inject the necessary environment variables into the Pods. +3. Restart the cert-manager Deployment + So that the EKS Pod Identity Agent can inject the necessary environment variables into the Pods. +4. **Create a `ClusterIssuer` resource** + + ```yaml + apiVersion: cert-manager.io/v1 + kind: ClusterIssuer + metadata: + name: letsencrypt-prod + spec: + acme: + ... + solvers: + - dns01: + route53 {}: + ``` #### EKS IAM Role for Service Accounts (IRSA) @@ -152,80 +167,100 @@ A mutating webhook, which is configured by default on EKS, will automatically se 1. **Create a trust relationship** -In this configuration an IAM role is mapped to the cert-manager `ServiceAccount` allowing it to authenticate with AWS. -The IAM role you map to the `ServiceAccount` will need permissions on any and all Route53 zones cert-manager will be using. -Create a trust relationship by adding the following trust policy to the IAM role: + In this configuration an IAM role is mapped to the cert-manager `ServiceAccount` allowing it to authenticate with AWS. + The IAM role you map to the `ServiceAccount` will need permissions on any and all Route53 zones cert-manager will be using. + Create a trust relationship by adding the following trust policy to the IAM role: + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": "sts:AssumeRoleWithWebIdentity", + "Principal": { + "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" + }, + "Condition": { + "StringEquals": { + "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::" + } + } + } + ] + } + ``` + + Replace the following: + + - `` with the AWS account ID of the EKS cluster. + - `` with the region where the EKS cluster is located. + - `` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`) + - `` with the namespace where cert-manager is running. + - `` with the name of the `ServiceAccount` object created by cert-manager. + + + > ℹ️ If you're following the Cross Account example, this trust policy is attached to the cert-manager role in Account X with ARN `arn:aws:iam::XXXXXXXXXXX:role/cert-manager`. + > The permissions policy is the same as above. -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": "sts:AssumeRoleWithWebIdentity", - "Principal": { - "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" - }, - "Condition": { - "StringEquals": { - "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::" - } - } - } - ] -} -``` - -Replace the following: +2. **Annotate the cert-manager `ServiceAccount`** -- `` with the AWS account ID of the EKS cluster. -- `` with the region where the EKS cluster is located. -- `` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`) -- `` with the namespace where cert-manager is running. -- `` with the name of the `ServiceAccount` object created by cert-manager. + ```yaml + apiVersion: v1 + kind: ServiceAccount + metadata: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXX:role/cert-manager + ``` + The cert-manager Helm chart provides a variable for injecting annotations into cert-manager's `ServiceAccount` like so: -> ℹ️ If you're following the Cross Account example above, this trust policy is attached to the cert-manager role in Account X with ARN `arn:aws:iam::XXXXXXXXXXX:role/cert-manager`. -> The permissions policy is the same as above. + ```yaml + serviceAccount: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXX:role/cert-manager + ``` -2. **Annotate the cert-manager `ServiceAccount`** + > ℹ️ If you're following the Cross Account example, modify the `ClusterIssuer` with the role from Account Y. -```yaml -apiVersion: v1 -kind: ServiceAccount -metadata: - annotations: - eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXX:role/cert-manager -``` +3. **(optional) Update file system permissions** -The cert-manager Helm chart provides a variable for injecting annotations into cert-manager's `ServiceAccount` like so: + You may also need to modify the cert-manager `Deployment` with the correct file system permissions, so the `ServiceAccount` token can be read. -```yaml -serviceAccount: - annotations: - eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXX:role/cert-manager -``` + ```yaml + spec: + template: + spec: + securityContext: + fsGroup: 1001 + ``` -> ℹ️ If you're following the Cross Account example above, modify the `ClusterIssuer` in the same way as above with the role from Account Y. + The cert-manager Helm chart provides a variable for modifying cert-manager's `Deployment` like so: -3. **(optional) Update file system permissions** + ```yaml + securityContext: + fsGroup: 1001 + ``` -You may also need to modify the cert-manager `Deployment` with the correct file system permissions, so the `ServiceAccount` token can be read. +4. **Restart the cert-manager Deployment** -```yaml -spec: - template: - spec: - securityContext: - fsGroup: 1001 -``` + Restart the cert-manager Deployment, so that the webhook can inject the + necessary `volume`, `volumemount`, and environment variables into the Pods. -The cert-manager Helm chart provides a variable for modifying cert-manager's `Deployment` like so: +5. **Create a `ClusterIssuer` resource** -```yaml -securityContext: - fsGroup: 1001 -``` + ```yaml + apiVersion: cert-manager.io/v1 + kind: ClusterIssuer + metadata: + name: letsencrypt-prod + spec: + acme: + ... + solvers: + - dns01: + route53 {}: + ``` ### Non-ambient Credentials @@ -250,109 +285,109 @@ such that each `ServiceAccount` is mapped to an IAM role that only has permissio 1. **Create a ServiceAccount** -In order to reference a `ServiceAccount` it must first exist. -Unlike normal IRSA the `eks.amazonaws.com/role-arn` annotation is not required. + In order to reference a `ServiceAccount` it must first exist. + Unlike normal IRSA the `eks.amazonaws.com/role-arn` annotation is not required. -```yaml -apiVersion: v1 -kind: ServiceAccount -metadata: - name: -``` + ```yaml + apiVersion: v1 + kind: ServiceAccount + metadata: + name: + ``` 2. **Create an IAM role trust policy** -For every `ServiceAccount` you want to use for AWS authentication you must first set up a trust policy: - -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": "sts:AssumeRoleWithWebIdentity", - "Principal": { - "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" - }, - "Condition": { - "StringEquals": { - "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::" - } - } - } - ] -} -``` - -Replace the following: - -- `` with the AWS account ID of the EKS cluster. -- `` with the region where the EKS cluster is located. -- `` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`) -- `` with the namespace of the `ServiceAccount` object. -- `` with the name of the `ServiceAccount` object. + For every `ServiceAccount` you want to use for AWS authentication you must first set up a trust policy: + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": "sts:AssumeRoleWithWebIdentity", + "Principal": { + "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" + }, + "Condition": { + "StringEquals": { + "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::" + } + } + } + ] + } + ``` + + Replace the following: + + - `` with the AWS account ID of the EKS cluster. + - `` with the region where the EKS cluster is located. + - `` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`) + - `` with the namespace of the `ServiceAccount` object. + - `` with the name of the `ServiceAccount` object. 3. **Create an RBAC Role and RoleBinding** -In order to allow cert-manager to issue a token using your `ServiceAccount` you must deploy some RBAC to the cluster: - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: Role -metadata: - name: -tokenrequest - namespace: -rules: - - apiGroups: [''] - resources: ['serviceaccounts/token'] - resourceNames: [''] - verbs: ['create'] ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: RoleBinding -metadata: - name: cert-manager--tokenrequest - namespace: -subjects: - - kind: ServiceAccount - name: - namespace: -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: Role - name: -tokenrequest -``` - -Replace the following: - -- `` name of the `ServiceAccount` object. -- `` namespace of the `ServiceAccount` object. -- `` name of cert-managers `ServiceAccount` object, as created during cert-manager installation. -- `` namespace that cert-manager is deployed into. + In order to allow cert-manager to issue a token using your `ServiceAccount` you must deploy some RBAC to the cluster: + + ```yaml + apiVersion: rbac.authorization.k8s.io/v1 + kind: Role + metadata: + name: -tokenrequest + namespace: + rules: + - apiGroups: [''] + resources: ['serviceaccounts/token'] + resourceNames: [''] + verbs: ['create'] + --- + apiVersion: rbac.authorization.k8s.io/v1 + kind: RoleBinding + metadata: + name: cert-manager--tokenrequest + namespace: + subjects: + - kind: ServiceAccount + name: + namespace: + roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: -tokenrequest + ``` + + Replace the following: + + - `` name of the `ServiceAccount` object. + - `` namespace of the `ServiceAccount` object. + - `` name of cert-managers `ServiceAccount` object, as created during cert-manager installation. + - `` namespace that cert-manager is deployed into. 4. **Create an Issuer or ClusterIssuer** -You should be ready at this point to configure an Issuer to use the new `ServiceAccount`. -You can see example config for this below: - -```yaml -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: example -spec: - acme: - ... - solvers: - - dns01: - route53: - region: us-east-1 - role: # This must be set so cert-manager what role to attempt to authenticate with - auth: - kubernetes: - serviceAccountRef: - name: # The name of the service account created -``` + You should be ready at this point to configure an Issuer to use the new `ServiceAccount`. + You can see example config for this below: + + ```yaml + apiVersion: cert-manager.io/v1 + kind: Issuer + metadata: + name: example + spec: + acme: + ... + solvers: + - dns01: + route53: + region: us-east-1 + role: # This must be set so cert-manager what role to attempt to authenticate with + auth: + kubernetes: + serviceAccountRef: + name: # The name of the service account created + ``` #### Referencing a long-term access key within in an Issuer or ClusterIssuer