Beispiele für Anwendungsfälle für Principal Access Boundary-Richtlinien

Im Folgenden finden Sie häufig vorkommende Situationen, in denen Sie Principal Access Boundary-Richtlinien verwenden können, und Beispiele für die Richtlinien und Richtlinienbindungen, die Sie in den einzelnen Situationen erstellen könnten. Informationen zum Erstellen von Principal Access Boundary-Richtlinien und zum Binden dieser Richtlinien an Hauptkontosätze finden Sie unter Principal Access Boundary-Richtlinien erstellen und anwenden.

Verhindern, dass Nutzer auf Ressourcen außerhalb Ihrer Organisation zugreifen

Da Principal Access Boundary-Richtlinien mit Hauptkonten und nicht mit Ressourcen verknüpft sind, können Sie damit verhindern, dass Hauptkonten auf Ressourcen zugreifen, die Ihnen nicht gehören. Sehen Sie sich dazu das folgende Szenario an:

Principal Access Boundary-Richtlinie, die den Zugriff auf eine Ressource verhindert

Principal Access Boundary-Richtlinie, die den Zugriff auf eine Ressource verhindert

  • Das Hauptkonto Tal (tal@example.com) gehört zur Google Workspace-Organisation example.com.
  • Tal hat die Rolle „Storage-Administrator“ (roles/storage.admin) für einen Cloud Storage-Bucket in einer anderen Organisation, cymbalgroup.com. Diese Rolle enthält die Berechtigung storage.objects.get, die zum Aufrufen von Objekten im Bucket erforderlich ist.
  • In cymbalgroup.com gibt es keine Ablehnungsrichtlinien, die Tal daran hindern, die Berechtigung storage.objects.get zu verwenden.

Die Administratoren von example.com können nicht mit Zulassungs- und Ablehnungsrichtlinien verhindern, dass Tal Objekte in diesem externen Bucket aufruft. Kein Hauptkonto von example.com ist berechtigt, die Zulassungsrichtlinie des Buckets zu bearbeiten, daher können sie die Rolle von Tal nicht widerrufen. Sie sind auch nicht berechtigt, Ablehnungsrichtlinien in cymbalgroup.com zu erstellen, daher können sie nicht mit einer Ablehnungsrichtlinie verhindern, dass Tal auf den Bucket zugreift.

Mit Principal Access Boundary-Richtlinien können die Administratoren von example.com jedoch verhindern, dass Tal Objekte im Bucket cymbalgroup.com oder in einem anderen Bucket außerhalb von example.com aufruft.

Dazu können die Administratoren eine Principal Access Boundary-Richtlinie erstellen, in der festgelegt ist, dass Hauptkonten von example.com nur auf Ressourcen in example.com zugreifen dürfen:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "4"
  }
}

Anschließend können sie eine Richtlinienbindung erstellen, um diese Richtlinie an alle Hauptkonten in der Organisation example.com anzuhängen:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Zu den Hauptkonten in example.com gehören alle Identitäten in der Domain example.com, alle Workforce Identity-Pools in example.com und alle Dienstkonten und Workload Identity-Pools in allen Projekten in example.com.

Mit dieser Richtlinie können die Hauptkonten in example.com keine Berechtigungen verwenden, die durch die Principal Access Boundary-Richtlinie blockiert werden, um auf Ressourcen außerhalb von example.com zuzugreifen, auch wenn sie diese Berechtigungen für diese Ressourcen haben.

In diesem Fall verwendet die Principal Access Boundary-Richtlinie die Erzwingungsversion 4, sodass die Berechtigung storage.objects.get blockiert werden kann. Daher kann Tal keine Objekte im Bucket cymbalgroup.com aufrufen, obwohl Tal die Rolle „Storage-Administrator“ für den Bucket hat.

Dienstkonten Zugriff auf Ressourcen in einem einzelnen Projekt gewähren

Sie können Principal Access Boundary-Richtlinien auch verwenden, um Teilmengen von Hauptkonten Zugriff auf Teilmengen von Ressourcen in Ihrer Organisation zu gewähren.

Angenommen, Sie haben ein Projekt example-dev mit der Projektnummer 901234567890. Sie möchten sicherstellen, dass die Dienstkonten in example-dev nur auf Ressourcen in example-dev zugreifen dürfen.

Dazu erstellen Sie zuerst eine neue Principal Access Boundary-Richtlinie, mit der Hauptkonten auf Ressourcen in dev-project zugreifen können:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "4"
  }
}

Diese Principal Access Boundary-Richtlinie verwendet die Erzwingungsversion 4, d. h., sie kann alle Berechtigungen blockieren, die in der Erzwingungsversion 4 unterstützt werden.

Nachdem Sie die Principal Access Boundary-Richtlinie erstellt haben, erstellen Sie eine Richtlinienbindung, um die neue Richtlinie an alle Hauptkonten in example-dev zu binden, und fügen Sie eine Bedingung hinzu, damit die Richtlinienbindung nur für Dienst konten gilt:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Wenn dies die einzige Principal Access Boundary-Richtlinie ist, die für die Dienstkonten gilt, können die Dienstkonten keine Berechtigungen verwenden, die durch die Principal Access Boundary-Richtlinie blockiert werden können, um auf Ressourcen außerhalb von example-dev zuzugreifen.

Berechtigung für verschiedene Hauptkontogruppen verwalten

Sie können mehrere Principal Access Boundary-Richtlinien in derselben Organisation verwenden, um verschiedenen Hauptkonten Zugriff auf verschiedene Ressourcen zu gewähren. Wenn Sie mehrere Principal Access Boundary-Richtlinien verwenden, verwenden Sie Bedingungen in Ihren Richtlinienbindungen, um sicherzustellen, dass jede Richtlinie nur für die Hauptkonten gilt, für die sie gelten soll.

Angenommen, Sie möchten, dass die meisten Hauptkonten auf alle Ressourcen in Ihrer Organisation zugreifen können, wie unter Verhindern, dass Nutzer auf Ressourcen außerhalb Ihrer Organisation zugreifen beschrieben. Sie möchten aber auch sicherstellen, dass die Dienstkonten in example-dev nur auf Ressourcen in example-dev zugreifen können, wie unter Dienstkonten Zugriff auf Ressourcen in einem einzelnen Projekt gewähren beschrieben.

Dazu gehen Sie so vor:

  1. Folgen Sie dem Beispiel unter Verhindern, dass Nutzer auf Ressourcen außerhalb von Ihrer Organisation zugreifen, und erstellen Sie eine Principal Access Boundary Richtlinie, mit der Hauptkonten auf Ressourcen in example.com zugreifen können. Binden Sie sie an den Hauptkontosatz der Organisation.

  2. Folgen Sie dem Beispiel unter Dienstkonten Zugriff auf Ressourcen gewähren in einem einzelnen Projekt und erstellen Sie eine Principal Access Boundary -Richtlinie, mit der Dienstkonten in example-dev auf Ressourcen in example-dev zugreifen können. Binden Sie sie an die Dienstkonten in example-dev.

  3. Sie schließen die Dienstkonten in example-dev von der Principal Access Boundary-Richtlinie aus, mit der Hauptkonten auf alle Ressourcen in example.com zugreifen können. Fügen Sie dazu der Richtlinienbindung, mit der diese Principal Access Boundary-Richtlinie an den Hauptkontosatz der Organisation angehängt wird, die folgende Bedingung hinzu:

    "condition": {
  "title": "Exempt example-dev service accounts",
  "description": "Don't enforce the policy for service accounts in the example-dev project",
  "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || (!principal.subject.endsWith('@example-dev.iam.gserviceaccount.com') && principal.subject != 'example-dev@appspot.gserviceaccount.com' && principal.subject != '901234567890-compute@developer.gserviceaccount.com')"
}

Dieser letzte Schritt ist entscheidend. Wenn Sie die Dienstkonten von example-dev nicht von der ursprünglichen Principal Access Boundary-Richtlinie ausschließen, können sie mit dieser Richtlinie auf alle Ressourcen in example.com zugreifen, unabhängig von den anderen Principal Access Boundary-Richtlinien, denen sie unterliegen. Weitere Informationen finden Sie unter Berechtigte Ressourcen definieren.

Außerdem ist es wichtig, eine neue Principal Access Boundary-Richtlinie zu erstellen und an die Dienstkonten von example-dev anzuhängen, bevor Sie sie von der ursprünglichen Principal Access Boundary-Richtlinie ausschließen. So wird sichergestellt, dass die Dienst konten immer mindestens einer Principal Access Boundary-Richtlinie unterliegen, wodurch verhindert wird, dass sie auf alleRessourcen zugreifen können Google Cloud. Weitere Informationen zum sicheren Reduzieren der Ressourcen, auf die ein Hauptkonto zugreifen kann, finden Sie unter Ressourcen reduzieren , auf die Hauptkonten zugreifen können.

Nächste Schritte