From 50246164dc2a6150106ff7a4b3dfbf4ad0f3e47f Mon Sep 17 00:00:00 2001 From: owais-rehman Date: Tue, 31 Dec 2024 16:04:48 +0500 Subject: [PATCH 1/4] updated docs according to comments received --- .../certificate-management/tls-certs.md | 34 +++++++++---------- .../expose-applications-to-internet.md | 12 +++---- 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md index 5af9557f..f726da22 100644 --- a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md +++ b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md @@ -8,28 +8,26 @@ Go to `common-shared-secret` path in Vault and create a secret `external-dns-cre ### Cloudflare -- `api-token (required)`: API token generated from DNS provider being used. In case of Cloudflare, it should have `DNS:Edit` and `Zone:Read` access. -- `domain-filter (optional)`: This field should contain base domain that becomes base for registering further subdomains. For example: `example.com`. -- `zone-id-filter (optional)`: In case of Cloudflare, if you want to give more restrictive access of only few zones to this token, then this field should contain these zone ids. +| Key | Required/Optional | Explanation | +|----------|----------|----------| +| `api-token` | required | API token generated from DNS provider being used. In case of Cloudflare, it should have following access
- `DNS:Edit`
- `Zone:Read` | +| `domain-filter` | optional | This field should contain base domain that becomes base for registering further subdomains. For example: `example.com`. | +| `zone-id-filter`| optional | In case of Cloudflare, if you want to give more restrictive access of only few zones to this token, then this field should contain these zone ids. -## Step 2: Navigate to the Target Path +## Step 2: Create Cert Manager Issuer Resource -Navigate to the appropriate path in your Infra GitOps repository. For this example, the path is: +Create following resources in your Infra GitOps repository at given path: ```plaintext /tenant-operator-config/templates/ ``` -## Step 3: Create Required Resources - -In this directory, create the following resources: - - [`Template`](https://docs.stakater.com/mto/main/crds-api-reference/template.html) - [`TemplateGroupInstance`](https://docs.stakater.com/mto/main/crds-api-reference/template-group-instance.html) ### Template -The `Template` resource defines the underlying YAML files to be deployed to tenant namespaces. Below is an example template for setting up a TLS certificate: +The `Template` resource defines the underlying YAML files to be deployed to tenant namespaces. Use the following template for setting up a TLS certificate: #### Cloudflare @@ -80,11 +78,13 @@ resources: #### Explanation of Resources -1. **`ExternalSecret`**: +**`ExternalSecret`**: + - Retrieves the `api-token` from the secret provider (Vault). - The `api-token` authenticates the DNS provider (e.g., Cloudflare) for certificate validation. -1. **`Issuer`**: +**`Issuer`**: + - Configures Cert-Manager to generate TLS certificates using [Let’s Encrypt](https://letsencrypt.org/). - Requires: - `.spec.acme.email`: Email address for certificate lifecycle updates. @@ -92,7 +92,7 @@ resources: ### TemplateGroupInstance -The `TemplateGroupInstance` deploys resources by referencing the created templates and specifying target namespaces. Example: +The `TemplateGroupInstance` deploys resources by referencing the created templates and specifying target namespaces: ```yaml apiVersion: tenantoperator.stakater.com/v1alpha1 @@ -103,9 +103,9 @@ spec: template: certificate-creds selector: matchExpressions: - - key: stakater.com/kind + - key: stakater.com/tenant operator: In - values: [sandbox, dev] + values: [ tenant1, tenant2 ] sync: true ``` @@ -113,11 +113,11 @@ spec: - **`.spec.template`**: References the `Template` resource. - **`.spec.selector`**: Specifies namespaces to deploy resources based on label expressions. - - In this example, resources are deployed to tenant namespaces with the label `stakater.com/kind` having values `sandbox` or `dev`. + - In this example, resources are deployed to tenant with the label `stakater.com/tenant` having values `tenant1` or `tenant2`. Commit, push, and merge these changes to the `main` branch. ArgoCD will deploy the resources to the specified namespaces within a few minutes. -### Verify Deployment +## Step 3: Validation 1. In the cluster console, switch to `Administrator` view and navigate to `Home > Search`. 1. Select the namespace and search for `Issuer` in the `Resources` dropdown. diff --git a/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md b/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md index 184da311..4bffcd44 100644 --- a/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md +++ b/content/for-developers/how-to-guides/expose-applications-to-internet/expose-applications-to-internet.md @@ -26,7 +26,7 @@ application: dnsNames: - issuerRef: - name: + name: kind: Issuer ``` @@ -37,7 +37,7 @@ application: - Requires: - `.certificate.secretName`: This is the name of secret that `Certificate` will create. It will contain TLS credentials that will find its utilization in next steps. - `.certificate.dnsNames`: DNS name for which this certificate will be valid. It can contain wildcard names like `*.example.com` or specific names like `api.example.com`. - - `.certificate.issuerRef.name`: Name of the issuer that this certificate will reference. We have created this issuer in previous steps. + - `.certificate.issuerRef.name`: Name of the issuer that this certificate will reference. We have created this issuer in previous steps. You can find this in the cluster console by switching to `Administrator` view and navigate to `Home > Search` and search for `Issuer` in your current namespace. ## Step 2: Deploy the Route @@ -71,7 +71,7 @@ application: - `route.host`: Specifies the host name that you want to use for this route. This value must match the `external-dns.alpha.kubernetes.io/hostname` annotation. - `route.path`: Specifies the URL path where your application will be exposed (e.g., `/api`). -### Verify Deployment +### Validation After updating the `values.yaml` file and applying the Helm chart, verify the deployment: @@ -93,6 +93,6 @@ After updating the `values.yaml` file and applying the Helm chart, verify the de 1. Navigate to the OpenShift cluster console. 1. Go to Networking > Routes and locate the Route resource for your application. 1. Confirm that: - - The Route resource is listed. - - Its status is Accepted. - - The DNS name and TLS configuration are correct. + - The Route resource is listed. + - Its status is Accepted. + - The DNS name and TLS configuration are correct. From d4fb8b78e79eeca64c0049dd63f242a8be1f0f07 Mon Sep 17 00:00:00 2001 From: owais-rehman Date: Tue, 31 Dec 2024 16:21:48 +0500 Subject: [PATCH 2/4] lint correction --- .../certificate-management/tls-certs.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md index f726da22..15cb05fe 100644 --- a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md +++ b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md @@ -80,15 +80,15 @@ resources: **`ExternalSecret`**: - - Retrieves the `api-token` from the secret provider (Vault). - - The `api-token` authenticates the DNS provider (e.g., Cloudflare) for certificate validation. +- Retrieves the `api-token` from the secret provider (Vault). +- The `api-token` authenticates the DNS provider (e.g., Cloudflare) for certificate validation. **`Issuer`**: - - Configures Cert-Manager to generate TLS certificates using [Let’s Encrypt](https://letsencrypt.org/). - - Requires: - - `.spec.acme.email`: Email address for certificate lifecycle updates. - - `.spec.acme.solvers.dns01.cloudflare.apiTokenSecretRef`: Reference to the `ExternalSecret` created earlier. +- Configures Cert-Manager to generate TLS certificates using [Let’s Encrypt](https://letsencrypt.org/). +- Requires: + - `.spec.acme.email`: Email address for certificate lifecycle updates. + - `.spec.acme.solvers.dns01.cloudflare.apiTokenSecretRef`: Reference to the `ExternalSecret` created earlier. ### TemplateGroupInstance From be5794550eb846026faaf2e7692a555efdacf0c5 Mon Sep 17 00:00:00 2001 From: owais-rehman Date: Tue, 31 Dec 2024 16:23:14 +0500 Subject: [PATCH 3/4] minor change --- .../how-to-guides/certificate-management/tls-certs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md index 15cb05fe..bc16f5b4 100644 --- a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md +++ b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md @@ -10,7 +10,7 @@ Go to `common-shared-secret` path in Vault and create a secret `external-dns-cre | Key | Required/Optional | Explanation | |----------|----------|----------| -| `api-token` | required | API token generated from DNS provider being used. In case of Cloudflare, it should have following access
- `DNS:Edit`
- `Zone:Read` | +| `api-token` | required | API token generated from DNS provider being used. In case of Cloudflare, it should have the following access
- `DNS:Edit`
- `Zone:Read` | | `domain-filter` | optional | This field should contain base domain that becomes base for registering further subdomains. For example: `example.com`. | | `zone-id-filter`| optional | In case of Cloudflare, if you want to give more restrictive access of only few zones to this token, then this field should contain these zone ids. From 7be159552d922985746af2acf1331f7194802c2a Mon Sep 17 00:00:00 2001 From: owais-rehman Date: Tue, 31 Dec 2024 17:58:51 +0500 Subject: [PATCH 4/4] updated docs a bit --- .../how-to-guides/certificate-management/tls-certs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md index bc16f5b4..5c49d65d 100644 --- a/content/for-administrators/how-to-guides/certificate-management/tls-certs.md +++ b/content/for-administrators/how-to-guides/certificate-management/tls-certs.md @@ -105,7 +105,7 @@ spec: matchExpressions: - key: stakater.com/tenant operator: In - values: [ tenant1, tenant2 ] + values: [ ] sync: true ``` @@ -113,7 +113,7 @@ spec: - **`.spec.template`**: References the `Template` resource. - **`.spec.selector`**: Specifies namespaces to deploy resources based on label expressions. - - In this example, resources are deployed to tenant with the label `stakater.com/tenant` having values `tenant1` or `tenant2`. + - In this example, resources are deployed to tenant with the label `stakater.com/tenant` having values `tenant1` or `tenant2`. Ensure this list includes the names of all tenants where the `Issuer` needs to be available. Whenever you add a new tenant requiring an `Issuer`, update this field to include its name. Commit, push, and merge these changes to the `main` branch. ArgoCD will deploy the resources to the specified namespaces within a few minutes.