Add cert-manager based installation instead of generating certs by script in job.

[gecube]

Preflight Checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions
• [ ] I have joined the ZITADEL chat

Describe your problem

I checked carefully the instructions for zitadel installation with secured postgresql. https://github.com/zitadel/zitadel-charts/tree/main/examples/2-postgres-secure I don't like the approach with the job as it is not flexible. For instance, it is easy to bootstrap the system, but what about rotation of certificates in future? So I'd prefer to switch to generation of certs by cert-manager. It gives a semi-automatic way to install everything and even more - cert-manager is capable of rotating the certificates is they are going to expire.

Describe your ideal solution

Provide the full set of manifests and instructions.

Version

No response

App version

No response

Additional Context

No response

[gecube]

I succeeded the installation with the next set of manifests:

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: "zitadel-pki-ca"
spec:
  commonName: "zitadel-ca"
  secretName: "zitadel-pki-ca"
  duration: 87600h # 3650d
  renewBefore: 8760h # 365d
  subject:
    organizations:
    - "ZITADEL PKI CA"
  usages:
  - "signing"
  - "key encipherment"
  - "cert sign"
  isCA: true
  issuerRef:
    name: "selfsigning-issuer"
    kind: ClusterIssuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: "zitadel-issuer"
spec:
  ca:
    secretName: "zitadel-pki-ca"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: postgres
spec:
  commonName: "db-postgresql"
  secretName: "postgres-cert"
  duration: 87600h # 3650d
  renewBefore: 8760h # 365d
  subject:
    organizations:
      - "ZITADEL POSTGRES"
  usages:
    - "key encipherment"
    - "server auth"
    - "data encipherment"
  dnsNames:
    - zitadel
    - postgres
    - postgresql
  issuerRef:
    name: zitadel-issuer
    kind: Issuer
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: zitadel
spec:
  commonName: "db-postgresql"
  secretName: "zitadel-cert"
  duration: 87600h # 3650d
  renewBefore: 8760h # 365d
  subject:
    organizations:
      - "ZITADEL POSTGRES"
  usages:
    - "key encipherment"
    - "server auth"
    - "data encipherment"
  dnsNames:
    - zitadel
    - postgres
    - postgresql
  issuerRef:
    name: zitadel-issuer
    kind: Issuer

global:
  storageClass: "standard-rwo"
volumePermissions:
  enabled: true
tls:
  enabled: true
  certificatesSecret: postgres-cert
  certFilename: "tls.crt"
  certKeyFilename: "tls.key"
auth:
  postgresPassword: "abc"

replicaCount: 1

zitadel:
  masterkey: olololololololololololololololololol
  configmapConfig:
    ExternalPort: 443
    ExternalSecure: true
    ExternalDomain: 35-99-18-124.sslip.io
    TLS:
      Enabled: false
    Database:
      Postgres:
        Host: postgresql
        Port: 5432
        Database: zitadel
        MaxOpenConns: 20
        MaxIdleConns: 10
        MaxConnLifetime: 30m
        MaxConnIdleTime: 5m
        User:
          Username: zitadel
          SSL:
            Mode: verify-full
        Admin:
          Username: postgres
          SSL:
            Mode: verify-full
  secretConfig:
    Database:
      Postgres:
        User:
          Password: xyz
        Admin:
          Password: abc

  dbSslCaCrtSecret: postgres-cert
  dbSslAdminCrtSecret: postgres-cert
  dbSslUserCrtSecret: zitadel-cert

[bdalpe]

Adding #207 would support this. That way Certificate resources can be configured as required by administrators and no assumptions are made regarding environments, resolvers, etc.