Add self-signed certificate init container

[PurseChicken]

Definition of Ready

• I am happy with the code
• Short description of the feature/issue is added in the pr description
• PR is linked to the corresponding user story
• Acceptance criteria are met
• All open todos and follow ups are defined in a new ticket and justified
• Deviations from the acceptance criteria and design are agreed with the PO and documented.
• No debug or dead code
• My code has no repetitions
• Documentation/examples are up-to-date
• All non-functional requirements are met
• If possible, the test configuration is adjusted so acceptance tests cover my changes

This PR adds the ability to enable an init container which will generate and store a self signed certificate for each pod that runs in the replica set.

The certificate is signed with the CN of "zitadel" and contains the following SAN's: localhost, Pod IP Address and Pod Name. Additionally, it can contain one more DNS name, specified in values, which will be added to the SAN.

By default, this is disabled in the values file, but if required can be enabled by setting selfSignedCert.enabled to true. You can add the DNS name you want to add the certificate in selfSignedCert.additionalDnsName. Omit this value if this is not required.

The init container uses a small alpine/openssl image to generate the certificate using the following command:

openssl req -nodes -x509 -sha256 -newkey rsa:4096 -keyout /etc/tls/tls.key -out /etc/tls/tls.crt -days 3560 -subj "/CN=zitadel" -addext "subjectAltName = DNS:localhost,DNS:${POD_IP},DNS:${POD_NAME}"

Enabling selfSignedCert also adds the correct volume and volumeMount for the /etc/tls directory. This is where the tls.crt and tls.key files will be stored. They can then be referenced in zitadel config directly. E.G. KeyPath: /etc/tls/tls.key CertPath: /etc/tls/tls.crt

[jessebot]

This would be great! After this branch has been rebased and possibly reviewed/merged, then we could use this feature in the values.yaml right?

zitadel:
  configmapConfig:
    TLS:
      Enabled: true
      
selfSignedCert:
  enabled: true
   additionalDnsName: zitadel.example.com

My only question is how can we rotate this cert periodically? And is there a way to use cert-manager to do this?

Also, if this gets run on every init, and you have multiple pods, wouldn't this overwrite the existing cert, or would it error if there's already a cert there?

[PurseChicken]

This would be great! After this branch has been rebased and possibly reviewed/merged, then we could use this feature in the values.yaml right?

zitadel:
  configmapConfig:
    TLS:
      Enabled: true
      
selfSignedCert:
  enabled: true
   additionalDnsName: zitadel.example.com

My only question is how can we rotate this cert periodically? And is there a way to use cert-manager to do this?

Also, if this gets run on every init, and you have multiple pods, wouldn't this overwrite the existing cert, or would it error if there's already a cert there?

You are partly correct.

Setting selfSignedCert.enabled: true will only enable the init container to generate the cert and store it at /etc/tls/tls.crt along with the key file at /etc/tls/tls.key. If you want to use them, then you also need to set your TLS config to use them. E.G.

zitadel:
  configmapConfig:
    TLS:
      Enabled: true
      KeyPath: /etc/tls/tls.key
      CertPath: /etc/tls/tls.crt

My only question is how can we rotate this cert periodically? And is there a way to use cert-manager to do this?

The cert is valid in the pod for as long as the pod is alive. Once the pod is restarted or deleted and recreated, then the init container runs again and regenerates the certificate. That effectively rotates the certificate and key.
I am sure that this could be expanded upon to use cert-manager, but I did not include that in my PR. Since this is strictly for generating a self-signed certificate, then this solution seemed to fit the bill.

Also, if this gets run on every init, and you have multiple pods, wouldn't this overwrite the existing cert, or would it error if there's already a cert there?

The pods each use their own volume mounts and certificates. They are not shared across pods. There would be no "overwriting", just unique certificate and key for each running pod.

[eliobischof]

@PurseChicken you closed the PR. Is it not relevant for you anymore or was there not enough response? Sorry for the delay.

[PurseChicken]

I inadvertently closed this. Its still relevant and should be re-opened.

[PurseChicken]

@eliobischof Can you reopen?

[eliobischof]

I can't because GitHub says that the fork was deleted (even though I can see the fork exists 🧐).
But I can create a new PR based on the changes in this PR.

[PurseChicken]

Sounds good. Thanks!

[PurseChicken]

Any update on this?

[PurseChicken]

@eliobischof bump. Should I just create a new PR?

[eliobischof]

@eliobischof bump. Should I just create a new PR?

If you have the time, I'appreciate it 🙏

[PurseChicken]

This has been resubmitted in #140