Limits für Aufbewahrungsrichtlinien erhöhen

In Google Distributed Cloud (GDC) Air-Gap gibt es eine Einschränkung, die Nutzer daran hindert, eine festgelegte maximale Aufbewahrungsrichtlinie GDCHRestrictAttributeRange zu überschreiten. Diese Einschränkung wird für benutzerdefinierte Bucket-Ressourcen (CRs) in den Organisationsadministratorclustern vom Policy Controller von Anthos Config Management erzwungen. Das bedeutet, dass standardmäßig nur die Systemdienstkonten, Systemnutzer und Nutzer in der Gruppe system:masters die Finalizer entfernen können. Im Folgenden wird beschrieben, wie Sie die Grenzwerte für die Aufbewahrungsrichtlinie für Bucket-CRs erhöhen.

Vorbereitung

KUBECONFIG-Datei für den Cluster generieren

Für kubectl-Befehle ist eine gültige KUBECONFIG-Datei erforderlich. In dieser Anleitung wird Schritt für Schritt beschrieben, wie Sie die KUBECONFIG-Datei für den Root-Administrator, den Organisationsadministrator, das Organisationssystem und die Nutzercluster generieren.

Vorbereitung

Bevor Sie fortfahren, benötigen Sie Folgendes:

  • gdcloud ist installiert.

  • Die kubectl-CLI ist installiert.

  • Ein installiertes, von einer Zertifizierungsstelle signiertes Zertifikat auf der Workstation.

  • Der Name der Organisation.

  • Die Stamm-URL (GDC). Der IT-Administrator der Organisationseinheit muss Ihnen die Stamm-URL zur Verfügung stellen.

Erforderliche Umgebungsvariablen festlegen

Folgen Sie der Anleitung in diesem Abschnitt, um die KUBECONFIG-Datei für org-admin, system oder einen beliebigen Nutzercluster zu generieren.

  1. Führen Sie den folgenden Befehl aus, um die Umgebungsvariable ORG für die spätere Verwendung im aktuellen Terminal zu definieren. ORG ist der Name Ihrer Organisation.

    export ORG=

  2. Führen Sie den folgenden Befehl aus, um die Umgebungsvariable CONSOLE_URL für die spätere Verwendung im aktuellen Terminal zu definieren:

    export CONSOLE_URL=https://console.${ORG:?}.$GDC_URL/
gdcloud config set core/organization_console_url ${CONSOLE_URL:?}

    Ersetzen Sie GDC_URL durch die Basis-URL für Ihr GDC-Projekt.

Beim Cluster anmelden

  1. Führen Sie den folgenden Befehl aus, um sich anzumelden:

    gdcloud auth login --no-browser

  2. Kopieren Sie den ausgegebenen gcloud-Befehl und führen Sie ihn auf einem Computer mit Browserzugriff aus.

  3. Kopieren Sie die ausgegebene URL und fügen Sie sie in die Adressleiste eines Webbrowsers ein.

  4. Folgen Sie der Anleitung auf der Webseite, um die Anmeldung abzuschließen.

  5. Nach erfolgreichem Abschluss der Anmeldung wird im Browser die Meldung Authentifizierung erfolgreich. Bitte schließen Sie dieses Fenster.

  6. Folgen Sie der Anleitung auf dem Terminal. Nach der erfolgreichen Anmeldung wird im Terminal die Meldung You are now logged in (Sie sind jetzt angemeldet) angezeigt.

KUBECONFIG-Datei generieren

  1. Führen Sie den folgenden Befehl aus, um die Umgebungsvariable CLUSTER für die spätere Verwendung im aktuellen Terminal zu definieren. CLUSTER ist der gewünschte Clusternamen.

    export CLUSTER=

    In der folgenden Tabelle finden Sie den Namen des Clusters. Ersetzen Sie dazu ORGANIZATION-NAME und CLUSTER-NAME durch die entsprechenden Werte:

    Cluster Clustername
    Root-Administrator root-admin
    Admin der Organisation ORGANIZATION-NAME-admin
    org-System ORGANIZATION-NAME-System
    Nutzer CLUSTER-NAME

    Jeder der Namen steht für Folgendes:

    • Der Name des Root-Administratorclusters ist root-admin.
    • Die Namen des Administratorclusters und des Systemclusters für eine Organisation mit dem Namen amira sind amira-admin bzw. amira-system.
    • Die Clusternamen für Nutzercluster sind ihre Clusternamen.

  2. Führen Sie den folgenden Befehl aus, um die KUBECONFIG-Datei zu generieren und die Anmeldedaten zu validieren: sh export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml rm ${KUBECONFIG:?} gdcloud clusters get-credentials ${CLUSTER:?} [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure" Der Befehl sollte die folgende Ausgabe zurückgeben:

    Success. Your kubeconfig is at /usr/local/google/home/iris/kubeconfig-amira-admin.yaml

Rolle „Policy Admin“ im Cluster erhalten

Mit diesem Verfahren erhalten Sie vorübergehend erhöhten Zugriff auf einen Cluster.

Vorbereitung

Bevor Sie fortfahren, benötigen Sie Folgendes:

  • Ein anderes IO, das als GitLab-Antragsgenehmiger fungiert. Der IO muss die Berechtigung haben, eine GitLab-Anfrage zu genehmigen.
  • Der Name des Clusters, auf den Sie zugreifen müssen. Beispiele: root-admin, org-1-admin.
  • Welche Rolle Sie einnehmen möchten. Beispiel: Role ClusterRole, ProjectRole oder OrganizationRole.
  • Die Rolle, die Sie übernehmen möchten.
  • Der Namespace des erforderlichen Zugriffs. Nicht erforderlich für ClusterRole und OrganizationRole.
  • Zugriff auf eine OC IT-Workstation.
  • Anmeldedaten für GitLab.

Skript mit erhöhten Berechtigungen ausführen

  1. Führen Sie das Skript elevated-access-script.sh im Verzeichnis private-cloud/operations/tools/ auf Ihrer Workstation aus.

  2. Beantworten Sie die Frage „Please enter the GDCH_URL of the cluster...“ (Bitte geben Sie die GDCH_URL des Clusters ein...) mit $GDCH_URL.

  3. Beantworten Sie die Frage „Enter Gitlab username:“ (GitLab-Nutzername eingeben) mit dem Nutzernamen, mit dem Sie sich in GitLab anmelden.

  4. Geben Sie bei der Frage „Enter Gitlab personal access token:“ (Geben Sie das persönliche Zugriffstoken für GitLab ein) das persönliche Zugriffstoken Ihres Kontos ein. So erstellen Sie ein persönliches Zugriffstoken:

    1. Öffnen Sie https://gitlab.$GDCH_URL/gdch/iac. Melden Sie sich in Ihrem IO Gitlab-Konto an.

    2. Wählen Sie Ihren Avatar aus.

    3. Wählen Sie Profil bearbeiten aus.

    4. Wählen Sie im Navigationsmenü Zugriffstokens aus.

    5. Geben Sie einen Namen und ein Ablaufdatum für das Token ein.

    6. Wählen Sie die gewünschten Bereiche aus.

    7. Wählen Sie Create personal access token (Persönliches Zugriffstoken erstellen) aus.

  5. Das Skript klont jetzt das Repository iac in Ihr lokales Verzeichnis.

  6. Beantworten Sie die Frage „Geben Sie Ihr IdP-Präfix ein“. IdP Prefix ist ein Präfix, das für jeden Identitätsanbieter spezifisch ist und vor jedem Nutzernamen in einem GDC-Cluster vorangestellt wird. Dieses Präfix kann auf zwei Arten gefunden werden:

    • Watch Commander konsultieren
    • Anleitungen aus der GDC-Einrichtung abrufen, insbesondere den Abschnitt „Identitäts- und Zugriffsverwaltung“ im Nutzerhandbuch für Betreiber.

    In der Regel besteht dieses Präfix aus einer Reihe von Wörtern, gefolgt von einem Trennzeichen, z.B. gdch-infra-operator-.

  7. Beantworten Sie die Frage „Geben Sie Ihren Nutzernamen ein“ mit dem Nutzernamen, mit dem Sie sich bei Ihrem Identitätsanbieter anmelden.

  8. Beantworten Sie die Frage „Enter the cluster you need the role for“ (Geben Sie den Cluster ein, für den Sie die Rolle benötigen) mit dem Namen des Clusters, für den Sie die Rolle benötigen.

  9. Sie werden vom Skript aufgefordert, einen Kubernetes-Rollentyp auszuwählen. Geben Sie den gewünschten Rollentyp ein.

  10. Beantworten Sie die Frage „Geben Sie die Rolle ein, die Sie übernehmen müssen“ mit dem Namen der Rolle.

  11. Geben Sie die Zugriffszeitdauer der Rolle ein. Die empfohlene Zugriffszeit beträgt 3 Stunden.

  12. Das Skript generiert drei YAML-Dateien.

    1. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/kustomization.yaml
    2. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/kustomization.yaml
    3. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/${ROLE}-binding.yaml

    Prüfen Sie, ob jede Datei korrekt ist, indem Sie Y drücken. Wenn Sie die Datei in vim bearbeiten möchten, drücken Sie N.

  13. Nachdem Sie alle Dateien bestätigt haben, überträgt das Script sie per Push in einen elevated_access-Branch in GitLab und erstellt eine Merge-Anfrage.

Anfrage für erhöhten Zugriff prüfen und genehmigen

In der folgenden Liste sind die Maßnahmen aufgeführt, die bei der Überprüfung und Genehmigung einer Anfrage für erweiterten Zugriff ergriffen werden:

  1. Ein anderer IO prüft die GitLab-Anfrage, einschließlich der Richtlinienkonfigurationsdateien, um die Anfrage entsprechend zu genehmigen.
  2. Sobald der IO die Anfrage genehmigt hat, gewährt das System den Zugriff für den angeforderten Zeitraum.
  3. Das System widerruft den Zugriff nach Ablauf der festgelegten Ablaufzeit.

Patcheinschränkung

Nachdem Sie den erforderlichen Zugriff erhalten haben, führen Sie den folgenden Befehl aus, um das neue Maximum für die Aufbewahrungsrichtlinie für Buckets festzulegen. In diesem Beispiel wird ein neues Maximum von 120 Tagen festgelegt. Aktualisieren Sie den Befehl jedoch mit dem Wert, der von Ihrem Plattformadministrator angefordert wird:

kubectl patch GDCHRestrictAttributeRange restrict-bucket-retention-policy -p '{"spec":{"parameters":{"attributeMaxValue":120}}}' --type=merge

Die Ausgabe sollte so aussehen:

gdchrestrictattributerange.constraints.gatekeeper.sh/restrict-bucket-retention-policy patched