Version: Weekly Build

Cluster-Ingress-CA-Optionen

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

Verfügbare Issuer-Typen

`certIssuer.type`	Beschreibung	Beispiel-Anwendungsszenario
`self-signed` (Standard)	Erzeugt lokal eine neue selbstsignierte CA, oder du stellst dein eigenes CA-Zertifikat und deinen eigenen Schlüssel (zum Beispiel deiner bestehenden Organisations-CA) unter `cluster.certificates.ca` bereit.	Schnellstart und Testumgebungen als Standard; Unternehmen mit zentraler CA-Verwaltung können eigenes CA-Material statt eines generierten bereitstellen.
`acme`	Verwendet das ACME-Protokoll (zum Beispiel Let's Encrypt) für automatisierte Zertifikatsausstellung und -erneuerung.	Automatisierte Zertifikatsverwaltung, Cloud-native Umgebungen.

Konfiguration

Wähle den Issuer in config.yaml mit codesphere.certIssuer.type. 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.

Self-signed (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) mitzubringen, statt OMS eine erzeugen zu lassen, stelle das Zertifikat deiner CA als certPem bereit und ihren privaten Schlüssel als das unten stehende Vault-Secret selfSignedCaKeyPem.

Der private Schlüssel für die CA muss in deinem 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

Gib für ACME die ACME-Server-URL, deine E-Mail-Adresse und optional eine EAB-Key-ID (External Account Binding) an. Der ACME-Private-Key und der EAB-Key sind Secrets und müssen in deinem SOPS-Vault hinterlegt werden.

Beispiel: ACME (Let's Encrypt, mit 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 im Deployment-Konfig):
          dnsSolver:
            config:
              cloudflare:
                apiTokenSecretRef:
                  name: acme-solver
                  key: api-token
          solverSecret:
            name: acme-solver
            data:
              api-token: <api-token>

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

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

hinweis

Die DNS-Solver-Konfiguration muss als Override im Deployment-Konfig hinzugefügt werden, passend zu deinem DNS-Provider (zum Beispiel Cloudflare oder Route53). Verwende für Cloudflare die Felder apiTokenSecretRef und solverSecret wie oben gezeigt.

Die richtige Option wählen

Self-signed (generiert): Am einfachsten einzurichten, aber Vertrauen muss an alle Nutzer und Geräte verteilt werden.
Self-signed (eigene CA): Empfohlen, wenn du bereits eine CA betreibst und bestehende Vertrauensinfrastruktur nutzen möchtest.
ACME: Am besten für automatisierte Zertifikatsausstellung und -erneuerung, ohne eine eigene CA zu betreiben.

Weiter geht's

Siehe Gateway und Lastverteilung für die Gateway-Konfiguration, über die diese Zertifikate bereitgestellt werden, und Netzwerk, Firewalls und DNS für die Planung, welcher Issuer verwendet werden soll.

Verfügbare Issuer-Typen​

Konfiguration​

Self-signed (Standard, oder eigene CA)​

ACME​