Fehlerbehebung bei "withcond" in Richtlinien und Rollenbindungen

Wenn Sie eine "allow"-Richtlinie aufrufen, enthält diese möglicherweise Rollennamen mit dem String withcond, gefolgt von einem Hashwert. Ein Rollenname kann beispielsweise so aussehen: roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8.

Auf dieser Seite wird erläutert, wann und warum der String withcond in einer "allow"-Richtlinie angezeigt wird. Außerdem werden Maßnahmen bei der Anzeige dieses Strings empfohlen.

Richtlinienversionen und bedingte Rollenbindungen

Eine "allow"-Richtlinie kann in verschiedener Form dargestellt werden. Jede Form wird als "allow"-Richtlinienversion bezeichnet.

In einer "allow"-Richtlinie der Version 1 enthalten einige Rollenbindungen möglicherweise den String withcond in einem Rollennamen, gefolgt von einem Hashwert:

{
  "bindings": [
    {
      "members": [
        "user:dana@example.com"
      ],
      "role": "roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Dieses Format gibt an, dass die Rollenbindung bedingt ist. Mit anderen Worten: Die Rolle wird nur gewährt, wenn bestimmte Bedingungen erfüllt sind.

In "allow"-Richtlinien der Version 1 werden diese Bedingungen nicht angezeigt. Wenn Sie den String withcond und einen Hashwert sehen, enthält die Rollenbindung eine Bedingung, die nicht sichtbar ist.

Lösung: Richtlinienversion 3 angeben

Damit Sie die gesamte "allow"-Richtlinie einschließlich der Bedingungen aufrufen und aktualisieren können, müssen Sie immer die Version 3 angeben, wenn Sie eine "allow"-Richtlinie abrufen oder festlegen. Führen Sie die Aufgaben in den folgenden Abschnitten aus, um die Version 3 anzugeben.

gcloud-Tool aktualisieren

Wenn Sie das Google Cloud CLI verwenden, führen Sie gcloud version aus, um ihre Versionsnummer zu prüfen. Die Ausgabe enthält einen String ähnlich wie Google Cloud CLI 279.0.0.

Wenn die Versionsnummer kleiner als 263.0.0 ist, führen Sie gcloud components update aus, um die gcloud CLI zu aktualisieren. In Version 263.0.0 und höher gibt die gcloud-Befehlszeile automatisch eine "allow"-Richtlinienversion an, die Bedingungen unterstützt.

Clientbibliotheken aktualisieren

Wenn Ihre Anwendung eine Clientbibliothek verwendet, gehen Sie so vor:

  1. Suchen Sie nach dem Namen und der Versionsnummer der Clientbibliothek und prüfen Sie dann die Liste der Clientbibliotheken, die "allow"-Richtlinienversionen unterstützen.

    • Wenn Sie bereits eine aktuelle Version der Clientbibliothek verwenden, die "allow"-Richtlinienversionen unterstützt, müssen Sie Ihre Clientbibliothek nicht aktualisieren. Fahren Sie mit dem nächsten Schritt fort.

    • Wenn Sie eine niedrigere Version der Clientbibliothek verwenden und eine höhere Version "allow"-Richtlinienversion unterstützt, aktualisieren Sie Ihre Clientbibliothek auf die neueste Version.

    • Wenn Sie eine Clientbibliothek verwenden, die keine "allow"-Richtlinienversionen unterstützt, können Sie Ihrer Anwendung eine weitere Clientbibliothek hinzufügen, die Richtlinienversionen unterstützt. Verwenden Sie diese Clientbibliothek, um mit "allow"-Richtlinien zu arbeiten. Alternativ können Sie die IAM REST API direkt verwenden.

  2. Aktualisieren Sie den Code in Ihrer Anwendung, mit dem "allow"-Richtlinien abgerufen und festgelegt werden:

REST API-Aufrufe aktualisieren

Wenn Ihre Anwendung die IAM REST API direkt verwendet, aktualisieren Sie den Code, der "allow"-Richtlinien abruft und festlegt:

Managementtools für Richtlinien aktualisieren

Wenn Sie lokale Kopien Ihrer "allow"-Richtlinien beibehalten, z. B. wenn Sie sie in einem Versionsverwaltungssystem speichern und als Code behandeln, müssen alle verwendeten Tools folgende Kriterien erfüllen:

  • Alle Anfragen zum Abrufen oder Festlegen einer "allow"-Richtlinie geben die Version 3 an.
  • Alle Anfragen zum Festlegen einer "allow"-Richtlinie enthalten in der Anfrage das Feld etag.

Wenn ein Tool diese Kriterien nicht erfüllt, suchen Sie nach einer aktualisierten Version des Tools.

Achten Sie außerdem darauf, dass Ihre Managementtools bedingte Rollenzuweisungen beibehalten und keine doppelte Rollenzuweisung hinzufügen, die keine Bedingung enthält. Betrachten Sie beispielsweise das folgende Szenario:

  1. Sie erteilen dem Nutzer vikram@example.com für den Ordner my-folder die Rolle "Dienstkonten erstellen" (roles/iam.serviceAccountCreator). Die "allow"-Richtlinie für den Ordner sieht in etwa so aus:

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BuFmmMhCsNY=",
  "version": 1
}

  2. Sie verwenden ein Tool, um die "allow"-Richtlinie abzurufen und in einem Versionsverwaltungssystem zu speichern.

  3. Sie fügen eine Bedingung hinzu, damit vikram@example.com Dienstkonten ausgehend von Datum und Uhrzeit in Berlin nur während der normalen Arbeitswoche erstellen kann. Die aktualisierte "allow"-Richtlinie sieht in etwa so aus:

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator",
      "condition": {
        "title": "work_week_only",
        "expression": "request.time.getDayOfWeek('Europe/Berlin') >= 1 && request.time.getDayOfWeek('Europe/Berlin') <= 5"
      }
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 3
}

  4. Sie verwenden ein Tool, um die aktualisierte "allow"-Richtlinie abzurufen. Das Tool fügt in die Anfrage der "allow"-Richtlinie keine "allow"-Richtlinienversion ein, sodass Sie eine "allow"-Richtlinie der Version 1 mit einem geänderten Rollennamen erhalten:

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 1
}

An dieser Stelle könnte das Managementtool die Bindung von vikram@example.com an die Rolle roles/iam.serviceAccountCreator als nicht mehr vorhanden betrachten und die ursprüngliche Rollenbindung an die "allow"-Richtlinie wiederherstellen wollen:

Zu vermeiden: Zusätzliche Rollenbindung ohne Bedingung

{
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    },
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BwWd3HjhKxE=",
  "version": 1
}

Diese Änderung ist nicht korrekt. In diesem Fall wird die Rolle roles/iam.serviceAccountCreator vikram@example.com unabhängig vom Wochentag zugewiesen. Folglich hat die Bedingung in der ersten Rollenbindung keine Wirkung.

Wenn Ihre Managementtools versuchen, dementsprechende Änderungen vorzunehmen, genehmigen Sie sie nicht. Aktualisieren Sie stattdessen Ihre Managementtools, damit diese in Anfragen die "allow"-Richtlinienversion 3 angeben.

Nächste Schritte