Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

updated docs according to comments received #364

Merged
merged 4 commits into from
Jan 1, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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 the following access <br> - `DNS:Edit` <br> - `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.
owais-rehman marked this conversation as resolved.
Show resolved Hide resolved

## 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
<cluster>/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

Expand Down Expand Up @@ -80,19 +78,21 @@ resources:

#### Explanation of Resources

1. **`ExternalSecret`**:
- Retrieves the `api-token` from the secret provider (Vault).
- The `api-token` authenticates the DNS provider (e.g., Cloudflare) for certificate validation.
**`ExternalSecret`**:

- Retrieves the `api-token` from the secret provider (Vault).
- The `api-token` authenticates the DNS provider (e.g., Cloudflare) for certificate validation.

**`Issuer`**:

1. **`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

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
Expand All @@ -103,21 +103,21 @@ spec:
template: certificate-creds
selector:
matchExpressions:
- key: stakater.com/kind
- key: stakater.com/tenant
operator: In
values: [sandbox, dev]
values: [ <comma separated tenant names list> ]
sync: true
```

#### Key Fields

- **`.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`. 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.

### 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.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ application:
dnsNames:
- <DNS for which we need to generate certificate for example:example.com>
issuerRef:
name: <cert manager's Issuer name. You can ask cluster admin for this>
name: <cert manager's Issuer name.>
kind: Issuer
```

Expand All @@ -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

Expand Down Expand Up @@ -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:

Expand All @@ -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.
Loading