Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Untergeordnete Zertifizierungsstelle erstellen

In diesem Dokument werden die Schritte zum Erstellen einer untergeordneten Zertifizierungsstelle (Sub-CA) beschrieben.

Untergeordnete Zertifizierungsstellen sind für die Ausstellung von Zertifikaten direkt an Endentitäten wie Nutzer, Computer und Geräte verantwortlich. Sie werden von einer übergeordneten Zertifizierungsstelle, oft der Root-Zertifizierungsstelle, kryptografisch signiert. Systeme, die der Root-CA vertrauen, vertrauen automatisch den untergeordneten Zertifizierungsstellen und den von ihnen ausgestellten Zertifikaten.

Der Signierer des CA-Zertifikats kann entweder eine andere CA sein, die in CA Service erstellt wurde, z. B. eine Stamm-CA, oder eine externe CA. Bei externen Zertifizierungsstellen generiert CA Service eine Zertifikatsignierungsanfrage (Certificate Signing Request, CSR), die von der externen Zertifizierungsstelle signiert werden muss.

Dieses Dokument richtet sich an Zielgruppen innerhalb der Gruppe der Anwendungsoperatoren, z. B. Anwendungsentwickler oder Data Scientists, die Zertifikatslebenszyklen in ihrem Projekt verwalten. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Hinweis

Bevor Sie eine untergeordnete Zertifizierungsstelle erstellen können, müssen Sie die erforderlichen Berechtigungen anfordern und Ihre Umgebung vorbereiten.

IAM-Rollen anfordern

Wenn Sie Zertifizierungsstellenressourcen erstellen, aktualisieren und löschen möchten, wenden Sie sich an den IAM-Admin Ihrer Organisation, um die Rolle Certificate Authority Service Admin (certificate-authority-service-admin) im Projekt-Namespace der Zertifizierungsstelle anzufordern.

Umgebung vorbereiten

Laden Sie die gdcloud CLI herunter und installieren Sie sie, falls noch nicht geschehen.
Installieren Sie die kubectl-Befehlszeile.
Generieren Sie eine kubeconfig-Datei, um den Zugriff auf kubectl zu konfigurieren.

Verwaltete untergeordnete Zertifizierungsstelle erstellen

Bei einer verwalteten untergeordneten Zertifizierungsstelle ist der Signierer des CA-Zertifikats eine andere Zertifizierungsstelle (Stammzertifizierungsstelle), die in CA Service erstellt wurde.

Wenn Sie eine verwaltete untergeordnete Zertifizierungsstelle erstellen möchten, wenden Sie eine benutzerdefinierte Ressource auf Ihre Distributed Cloud Appliance-Instanz an.

Erstellen Sie eine CertificateAuthority-Ressource und speichern Sie sie als YAML-Datei mit dem Namen subca.yaml:

apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  Name: SUB_CA_NAME
  namespace: USER_PROJECT_NAMESPACE
spec:
  caProfile:
    commonName: COMMON_NAME
    duration: DURATION
    renewBefore: RENEW_BEFORE
    organizations:
    - ORGANIZATIONS
    organizationalUnits:
    - ORGANIZATIONAL_UNITS
    countries:
    - COUNTRIES
    localities:
    - LOCALITIES
    provinces:
    - PROVINCES
    streetAddresses:
    - STREET_ADDRESSES
    postalCodes:
    - POSTAL_CODES
  caCertificate:
    managedSubCA:
      certificateAuthorityRef:
        name: ROOT_CA_NAME
        namespace: USER_PROJECT_NAMESPACE
  certificateProfile:
    keyUsage:
      - digitalSignature
      - keyCertSign
      - crlSign
    extendedKeyUsage:
      - EXTENDED_KEY_USAGE
  secretConfig:
    secretName: SECRET_NAME
    privateKeyConfig:
      algorithm: KEY_ALGORITHM
      size: KEY_SIZE
  acme:
    enabled: ACME_ENABLED

Ersetzen Sie die folgenden Variablen:

Variable	Beschreibung
`SUB_CA_NAME`	Der Name der untergeordneten Zertifizierungsstelle.
`USER_PROJECT_NAMESPACE`	Der Name des Namespace, in dem sich das Nutzerprojekt befindet.
`COMMON_NAME`	Der allgemeine Name des CA-Zertifikats.
`DURATION`	Die angeforderte Lebensdauer des CA-Zertifikats. Geben Sie die Dauer in Stunden an (z. B. `1000h`). Einheiten wie Tage (`d`) oder Jahre (`y`) werden nicht unterstützt.
`ROOT_CA_NAME`	Der Name der Stammzertifizierungsstelle.
`SECRET_NAME`	Der Name des Kubernetes-Secrets, das den privaten Schlüssel und das signierte CA-Zertifikat enthält.

Die folgenden Variablen sind optionale Werte:

Variable	Beschreibung
`RENEW_BEFORE`	Die Rotationszeit, bevor das CA-Zertifikat abläuft.
`ORGANIZATIONS`	Organisationen, die im Zertifikat verwendet werden sollen.
`ORGANIZATIONAL_UNITS`	Organisationseinheiten, die im Zertifikat verwendet werden sollen.
`COUNTRIES`	Länder, die im Zertifikat verwendet werden sollen.
`LOCALITIES`	Städte, die im Zertifikat verwendet werden sollen.
`PROVINCES`	Bundesland oder Provinz, die im Zertifikat verwendet werden sollen.
`STREET_ADDRESSES`	Adressen, die auf dem Zertifikat verwendet werden sollen.
`POSTAL_CODES`	Postleitzahlen, die auf dem Zertifikat verwendet werden sollen.
`EXTENDED_KEY_USAGE`	Die erweiterte Schlüsselverwendung für das Zertifikat. Wenn angegeben, sind die zulässigen Werte `serverAuth` und `clientAuth`.
`KEY_ALGORITHYM`	Der für dieses Zertifikat verwendete Algorithmus für den privaten Schlüssel. Zulässige Werte sind RSA, Ed25519 oder ECDSA. Wenn die Größe nicht angegeben ist, wird standardmäßig 256 für ECDSA und 2048 für RSA verwendet. Die Schlüsselgröße wird für Ed25519 ignoriert.
`KEY_SIZE`	Die Größe des privaten Schlüssels für dieses Zertifikat in Bit hängt vom Algorithmus ab. RSA lässt 2048, 3072, 4096 oder 8192 zu (Standardwert: 2048). ECDSA lässt 256, 384 oder 521 zu (Standardwert 256). Ed25519 ignoriert die Größe.
`ACME_ENABLED`	Wenn dieser Wert auf `true` gesetzt ist, wird die Zertifizierungsstelle im ACME-Modus ausgeführt und die ACME-Server-URL ausgegeben. Anschließend können Sie den ACME-Client und das ACME-Protokoll verwenden, um Zertifikate zu verwalten.

Wenden Sie die benutzerdefinierte Ressource auf Ihre Distributed Cloud-Instanz an:
```
kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
```
Ersetzen Sie MANAGEMENT_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Management API-Servers.

Prüfen Sie die Bereitschaft der untergeordneten Zertifizierungsstelle. Es dauert etwa 40 Minuten, bis die Zertifizierungsstelle bereit ist:

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' 
.status.conditions[] | select( .type as $id | "Ready" | index($id))'

Die Ausgabe sieht dann ungefähr so aus:

{
  "lastTransitionTime": "2025-01-24T17:09:29Z",
  "message": "CA reconciled",
  "observedGeneration": 2,
  "reason": "Ready",
  "status": "True",
  "type": "Ready"
}

Sub-CA aus einer externen CA erstellen

Diese untergeordnete Zertifizierungsstelle unterstützt das Signieren von untergeordneten Zertifikaten mit externen oder vom Nutzer verwalteten Zertifizierungsstellen. Es wird eine CSR generiert, die Nutzer signieren können.

Erstellen Sie eine CertificateAuthority-Ressource und speichern Sie sie als YAML-Datei mit dem Namen subca-external.yaml:

apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  Name: SUB_CA_NAME
  namespace: USER_PROJECT_NAMESPACE
spec:
  caProfile:
    commonName: COMMON_NAME
    duration: DURATION
    renewBefore: RENEW_BEFORE
    organizations:
    - ORGANIZATION
    organizationalUnits:
    - ORGANIZATIONAL_UNITS
    countries:
    - COUNTRIES
    localities:
    - LOCALITIES
    provinces:
    - PROVINCES
    streetAddresses:
    - STREET_ADDRESSES
    postalCodes:
    - POSTAL_CODES
  caCertificate:
    externalCA: {}
  certificateProfile:
    keyUsage:
      - digitalSignature
      - keyCertSign
      - crlSign
    extendedKeyUsage:
      - EXTENDED_KEY_USAGE
  secretConfig:
    secretName: SECRET_NAME
    privateKeyConfig:
      algorithm: KEY_ALGORITHM
      size: KEY_SIZE
  acme:
    enabled: ACME_ENABLED

Ersetzen Sie die folgenden Variablen:

Variable	Beschreibung
`SUB_CA_NAME`	Der Name der untergeordneten Zertifizierungsstelle.
`USER_PROJECT_NAMESPACE`	Die Projekt-ID für das Projekt, in das Sie das Image importieren möchten.
`COMMON_NAME`	Der allgemeine Name des CA-Zertifikats.
`DURATION`	Die angeforderte Lebensdauer des CA-Zertifikats. Geben Sie die Dauer in Stunden an (z. B. `1000h`). Einheiten wie Tage (`d`) oder Jahre (`y`) werden nicht unterstützt.
`SECRET_NAME`	Der Name des Kubernetes-Secrets, das den privaten Schlüssel und das signierte CA-Zertifikat enthält.

Die folgenden Variablen sind optionale Werte:

Variable	Beschreibung
`RENEW_BEFORE`	Die Rotationszeit, bevor das CA-Zertifikat abläuft.
`ORGANIZATION`	Organisation, die im Zertifikat verwendet werden soll.
`ORGANIZATIONAL_UNITS`	Organisationseinheiten, die im Zertifikat verwendet werden sollen.
`COUNTRIES`	Länder, die im Zertifikat verwendet werden sollen.
`LOCALITIES`	Städte, die im Zertifikat verwendet werden sollen.
`PROVINCES`	Bundesland oder Provinz, die im Zertifikat verwendet werden sollen.
`STREET_ADDRESSES`	Adressen, die auf dem Zertifikat verwendet werden sollen.
`POSTAL_CODES`	Postleitzahlen, die auf dem Zertifikat verwendet werden sollen.
`EXTENDED_KEY_USAGE`	Die erweiterte Schlüsselverwendung für das Zertifikat. Wenn angegeben, sind die zulässigen Werte `serverAuth` und `clientAuth`.
`KEY_ALGORITHYM`	Der für dieses Zertifikat verwendete Algorithmus für den privaten Schlüssel. Zulässige Werte sind `RSA`, `Ed25519` oder `ECDSA`. Wenn die Größe nicht angegeben ist, wird standardmäßig 256 für `ECDSA` und 2048 für `RSA` verwendet. Die Schlüsselgröße wird für `Ed25519` ignoriert.
`KEY_SIZE`	Die Größe des privaten Schlüssels für dieses Zertifikat in Bit hängt vom Algorithmus ab. `RSA` lässt 2048, 3072, 4096 oder 8192 zu (Standardwert: 2048). `ECDSA` lässt 256, 384 oder 521 zu (Standard: 256). `Ed25519` ignoriert die Größe.
`ACME_ENABLED`	Wenn dieser Wert auf `true` gesetzt ist, wird die Zertifizierungsstelle im ACME-Modus ausgeführt und die ACME-Server-URL ausgegeben. Anschließend können Sie den ACME-Client und das ACME-Protokoll verwenden, um Zertifikate zu verwalten.

Wenden Sie die benutzerdefinierte Ressource auf Ihre Distributed Cloud-Instanz an:

kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG

Im GDC Management API-Server wird eine CSR für die untergeordnete CA generiert. Sie müssen die CSR herunterladen und signieren. Nach der Signierung können Sie das signierte Zertifikat auf den GDC Management API-Server hochladen.
Erfassen Sie die Anfragen zur Zertifikatssignierung (Certificate Signing Request, CSR) aus Ihrer Distributed Cloud-Umgebung:
```
kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
```
Mit dem Befehl wird im aktuellen Verzeichnis eine CSR-Datei mit dem Namen sub_ca.csr generiert. Diese Datei enthält eine CSR für ein X.509 CA-Zertifikat.
Verwenden Sie die Stammzertifizierungsstelle des Kunden, um signierte CA-Zertifikate für die Datei sub_ca.csr anzufordern.
Für eine genehmigte Zertifikatsignierungsanfrage müssen Sie ein CA-Zertifikat abrufen, das von der Stammzertifizierungsstelle des Kunden signiert wurde. Speichern Sie das Zertifikat in der Datei sub_ca.crt im aktuellen Verzeichnis.
Rufen Sie gegebenenfalls das Root-CA-Zertifikat des Kunden ab und speichern Sie es in der Datei ca.crt im aktuellen Verzeichnis.
Prüfen Sie den Common Name (CN) des CA-Zertifikats:
```
openssl x509 -noout -subject -in sub_ca.crt
```
Wenn Ihre Einrichtung SAN-Erweiterungen (Subject Alternative Name) erfordert, prüfen Sie die SAN-Erweiterungen im Zertifikat:
```
openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
```

Generieren Sie die spec, um die CertificateAuthority-Ressource zu patchen:

echo "spec:
  caCertificate:
    externalCA:
      signedCertificate:
        certificate: $(base64 -w0 SUB_CA_NAME.crt)
        ca: $(base64 -w0 ca.crt)" > patch.txt

Der Inhalt der Datei patch.txt sieht in etwa so aus:

spec:
  caCertificate:
    externalCA:
      signedCertificate:
        certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ…
        ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…

Bearbeiten Sie das Feld spec der Ressource CertificateAuthority:

kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'

Prüfen Sie die Bereitschaft der BYO-Sub-CA (Bring Your Own). Es dauert normalerweise etwa 40 Minuten, bis die CA bereit ist:

kubectl -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'

Die Ausgabe sieht dann ungefähr so aus:

{
  "lastTransitionTime": "2024-04-30T22:10:50Z",
  "message": "Certificate authority is ready for use",
  "observedGeneration": 3,
  "reason": "Ready",
  "status": "True",
  "type": "Ready"
}

Prüfen Sie das Ablaufdatum der signierten CA-Zertifikate:

kubectl -n USER_PROJECT_NAMESPACE get secret SECRET_NAME -ojson | jq -j '"echo ", .metadata.name, " $(echo ", .data["tls.crt"], "| base64 -d | openssl x509 -enddate -noout)\n"' | bash

Zertifizierungsstellen auflisten

So listen Sie alle Certificate Authority Service-Ressourcen in Ihrer Distributed Cloud-Instanz mit Air Gap auf:

Verwenden Sie den Parameter certificateauthorities, um alle CertificateAuthority-Ressourcen aufzulisten:

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities

Die Ausgabe sieht dann ungefähr so aus:

   NAMESPACE    NAME              READY   REASON   AGE
   foo          root-ca           True    Ready    7h24m
   foo          sub-ca            True    Ready    7h24m

Untergeordnete Zertifizierungsstelle erstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweis

IAM-Rollen anfordern

Umgebung vorbereiten

Verwaltete untergeordnete Zertifizierungsstelle erstellen

Sub-CA aus einer externen CA erstellen

Zertifizierungsstellen auflisten

Untergeordnete Zertifizierungsstelle erstellen