Format the numbered list items

Signed-off-by: Richard Wall <[email protected]>
cert-manager · Oct 8, 2024 · 613a2fa · 613a2fa
1 parent df1b6bf
commit 613a2fa
Showing 1 changed file with 189 additions and 154 deletions.
diff --git 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::<aws-account-id>:oidc-provider/oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>"
+         },
+         "Condition": {
+           "StringEquals": {
+             "oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>:sub": "system:serviceaccount:<namespace>:<service-account-name>"
+           }
+         }
+       }
+     ]
+   }
+   ```
+
+   Replace the following:
+
+   - `<aws-account-id>` with the AWS account ID of the EKS cluster.
+   - `<aws-region>` with the region where the EKS cluster is located.
+   - `<eks-hash>` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`)
+   - `<namespace>` with the namespace where cert-manager is running.
+   - `<service-account-name>` 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::<aws-account-id>:oidc-provider/oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>"
-      },
-      "Condition": {
-        "StringEquals": {
-          "oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>:sub": "system:serviceaccount:<namespace>:<service-account-name>"
-        }
-      }
-    }
-  ]
-}
-```
-
-Replace the following:
+2. **Annotate the cert-manager `ServiceAccount`**
 
-- `<aws-account-id>` with the AWS account ID of the EKS cluster.
-- `<aws-region>` with the region where the EKS cluster is located.
-- `<eks-hash>` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`)
-- `<namespace>` with the namespace where cert-manager is running.
-- `<service-account-name>` 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: <service-account-name>
-```
+   ```yaml
+   apiVersion: v1
+   kind: ServiceAccount
+   metadata:
+     name: <service-account-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::<aws-account-id>:oidc-provider/oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>"
-      },
-      "Condition": {
-        "StringEquals": {
-          "oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>:sub": "system:serviceaccount:<namespace>:<service-account-name>"
-        }
-      }
-    }
-  ]
-}
-```
-
-Replace the following:
-
-- `<aws-account-id>` with the AWS account ID of the EKS cluster.
-- `<aws-region>` with the region where the EKS cluster is located.
-- `<eks-hash>` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`)
-- `<namespace>` with the namespace of the `ServiceAccount` object.
-- `<service-account-name>` 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::<aws-account-id>:oidc-provider/oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>"
+         },
+         "Condition": {
+           "StringEquals": {
+             "oidc.eks.<aws-region>.amazonaws.com/id/<eks-hash>:sub": "system:serviceaccount:<namespace>:<service-account-name>"
+           }
+         }
+       }
+     ]
+   }
+   ```
+
+   Replace the following:
+
+   - `<aws-account-id>` with the AWS account ID of the EKS cluster.
+   - `<aws-region>` with the region where the EKS cluster is located.
+   - `<eks-hash>` with the hash in the EKS API URL; this will be a random 32 character hex string (example: `45DABD88EEE3A227AF0FA468BE4EF0B5`)
+   - `<namespace>` with the namespace of the `ServiceAccount` object.
+   - `<service-account-name>` 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: <service-account-name>-tokenrequest
-  namespace: <service-account-namespace>
-rules:
-  - apiGroups: ['']
-    resources: ['serviceaccounts/token']
-    resourceNames: ['<service-account-name>']
-    verbs: ['create']
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-<service-account-name>-tokenrequest
-  namespace: <service-account-namespace>
-subjects:
-  - kind: ServiceAccount
-    name: <cert-manager-service-account-name>
-    namespace: <cert-manager-namespace>
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: Role
-  name: <service-account-name>-tokenrequest
-```
-
-Replace the following:
-
-- `<service-account-name>` name of the `ServiceAccount` object.
-- `<service-account-namespace>` namespace of the `ServiceAccount` object.
-- `<cert-manager-service-account-name>` name of cert-managers `ServiceAccount` object, as created during cert-manager installation.
-- `<cert-manager-namespace>` 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: <service-account-name>-tokenrequest
+     namespace: <service-account-namespace>
+   rules:
+     - apiGroups: ['']
+       resources: ['serviceaccounts/token']
+       resourceNames: ['<service-account-name>']
+       verbs: ['create']
+   ---
+   apiVersion: rbac.authorization.k8s.io/v1
+   kind: RoleBinding
+   metadata:
+     name: cert-manager-<service-account-name>-tokenrequest
+     namespace: <service-account-namespace>
+   subjects:
+     - kind: ServiceAccount
+       name: <cert-manager-service-account-name>
+       namespace: <cert-manager-namespace>
+   roleRef:
+     apiGroup: rbac.authorization.k8s.io
+     kind: Role
+     name: <service-account-name>-tokenrequest
+   ```
+
+   Replace the following:
+
+   - `<service-account-name>` name of the `ServiceAccount` object.
+   - `<service-account-namespace>` namespace of the `ServiceAccount` object.
+   - `<cert-manager-service-account-name>` name of cert-managers `ServiceAccount` object, as created during cert-manager installation.
+   - `<cert-manager-namespace>` 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: <iam-role-arn> # This must be set so cert-manager what role to attempt to authenticate with
-          auth:
-            kubernetes:
-              serviceAccountRef:
-                name: <service-account-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: <iam-role-arn> # This must be set so cert-manager what role to attempt to authenticate with
+             auth:
+               kubernetes:
+                 serviceAccountRef:
+                   name: <service-account-name> # The name of the service account created
+   ```
 
 #### Referencing a long-term access key within in an Issuer or ClusterIssuer