Cluster Ingress CA-Optionen

Codesphere unterstützt zwei Möglichkeiten, Zertifikate für den Ingress-Traffic innerhalb des Clusters auszustellen, ausgewählt über codesphere.certIssuer.type.

Verfügbare Issuer-Typen

certIssuer.type	Beschreibung	Beispiel-Anwendungsszenario
self-signed (Standard)	Generiert lokal eine neue selbstsignierte CA oder stellt die eigene CA-Zertifikat und den Schlüssel (zum Beispiel die bestehende CA der eigenen Organisation) unter cluster.certificates.ca bereit.	Standardmäßig für Schnellstart- und Testumgebungen; Unternehmen mit einer zentralen CA können ihr eigenes CA-Material bereitstellen, anstatt eines zu generieren.
acme	Verwendet das ACME-Protokoll (zum Beispiel Let's Encrypt) zur automatisierten Ausstellung und Erneuerung von Zertifikaten.	Automatisiertes Zertifikatsmanagement, Cloud-native Umgebungen.

Konfiguration

In config.yaml wird der Issuer mit codesphere.certIssuer.type ausgewählt. Der Legacy-Block cluster.certificates.ca enthält das CA-Material für den Typ self-signed; ACME wird vollständig unter codesphere.certIssuer.acme und cluster.certificates.override konfiguriert.

Selbstsigniert (Standard oder eigene CA)

codesphere:
  certIssuer:
    type: self-signed
cluster:
  certificates:
    ca:
      algorithm: RSA # oder ECDSA
      keySizeBits: 2048 # oder 4096 usw.
      certPem: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----

Um eine eigene CA (zum Beispiel eine Organisations-CA) einzubringen, anstatt OMS eine generieren zu lassen, wird das Zertifikat der eigenen CA als certPem und der zugehörige private Schlüssel als das unten beschriebene selfSignedCaKeyPem-Vault-Secret bereitgestellt.

Der private Schlüssel der CA muss im SOPS-Vault (prod.vault.yaml) unter dem Schlüssel selfSignedCaKeyPem gespeichert werden:

secrets:
  - name: selfSignedCaKeyPem
    file:
      name: ca.key
      content: |
        -----BEGIN PRIVATE KEY-----
        ...
        -----END PRIVATE KEY-----

ACME

Für ACME müssen die ACME-Server-URL, die eigene E-Mail-Adresse und optional eine EAB-Key-ID (External Account Binding) angegeben werden. Der private ACME-Schlüssel und der EAB-Schlüssel sind Secrets und müssen dem SOPS-Vault hinzugefügt werden.

Beispiel: ACME (Let's Encrypt, mit einem Cloudflare-DNS-Solver)

codesphere:
  certIssuer:
    type: acme
    acme:
      server: https://acme-v02.api.letsencrypt.org/directory
      email: [email protected]
      eabKeyId: <optional-eab-key-id>
cluster:
  certificates:
    override:
      issuers:
        acme:
          # DNS-Solver-Konfiguration (Override in der Deployment-Konfiguration):
          dnsSolver:
            config:
              cloudflare:
                apiTokenSecretRef:
                  name: acme-solver
                  key: api-token
          solverSecret:
            name: acme-solver
            data:
              api-token: <api-token>

Der EAB-MAC-Schlüssel muss, falls verwendet, unter dem Schlüssel acmeEabMacKey gespeichert werden:

secrets:
  - name: acmeEabMacKey
    fields:
      key: <your-eab-mac-key>

hinweis

Die DNS-Solver-Konfiguration muss als Override in der Deployment-Konfiguration hinzugefügt werden, passend zum jeweiligen DNS-Provider (zum Beispiel Cloudflare oder Route53). Für Cloudflare werden die Felder apiTokenSecretRef und solverSecret wie oben gezeigt verwendet.

Die richtige Option wählen

• Selbstsigniert (generiert): Am einfachsten einzurichten, aber das Vertrauen muss an alle Nutzer und Geräte verteilt werden.
• Selbstsigniert (eigene CA): Empfohlen, wenn bereits eine eigene CA betrieben wird und die bestehende Vertrauensinfrastruktur genutzt werden soll.
• ACME: Am besten geeignet für die automatisierte Ausstellung und Erneuerung von Zertifikaten, ohne eine eigene CA zu betreiben.

Weiterführend

Siehe Gateway und Load Balancing für die Gateway-Konfiguration, aus der diese Zertifikate bereitgestellt werden, und Netzwerk, Firewalls und DNS für die Planung, welcher Issuer verwendet werden soll.