Caputchin
Teams

Dein erstes geteiltes Team erstellen

Am Ende dieses Tutorials hast du ein geteiltes Team erstellt und drei Personen hineingeladen, jede mit einem bewusst anderen Satz Berechtigungen: einen Operations-Lead, der das Team führt, einen Entwickler, der ein Produkt konfiguriert, und eine Managerin, die nur die Zahlen liest. Wir folgen BananaSeed, einem Unternehmen, dessen Gründerin ein Team aufbaut.

Du brauchst einen bezahlten Tarif, der geteilte Teams enthält (Troop oder Apex). Auf Solo oder Alpha hast du nur dein persönliches Team, das dir allein gehört. Sieh dir Abrechnung für Tarife an, was ein Team ist für das Konzept und Berechtigungen und Geltungsbereich für das Modell, auf das die Rollen unten zurückgreifen.

Das Setup

BananaSeeds Gründerin Ana ist ihrem persönlichen Team entwachsen. Sie hat zwei Produkte, jedes mit eigenem Site-Key, und drei Personen mitzubringen:

PersonRolleSoll können
DanaDevOpsDas Team führen: Mitglieder und Access Tokens verwalten.
RajEntwicklerDen Site-Key eines Produkts anpassen, sonst nichts.
MiaManagerinDie Zahlen über das Team hinweg ansehen. Nichts ändern.

Jede bildet eine der vier Berechtigungen ab: Dana braucht Verwalten, Raj braucht Bearbeiten auf einem Key, Mia braucht Lesen.

1. Das Team und seine Keys erstellen

Erstell aus der Team-Liste des Dashboards ein Team namens BananaSeed. Es startet mit nur dir, der Inhaberin, die jede Berechtigung hält. Erstell die zwei Site-Keys darin, shop.bananaseed.com und blog.bananaseed.com, damit es etwas gibt, worauf du Personen einschränken kannst. (Sieh dir Site-Keys an.)

2. Dana einladen, die DevOps-Lead (Verwalten)

Lade Dana auf der Mitglieder-Seite des Teams per E-Mail ein. Die Einladung ist die E-Mail-Adresse selbst; meldet sich Dana mit dieser Adresse an, ist ihre Mitgliedschaft live.

Gewähr ihr nur Verwalten. Diese eine Berechtigung ist die Team-Administration: sie kann Mitglieder und Access Tokens hinzufügen, entfernen und ändern und das Team umbenennen oder löschen. Weil Verwalten teamweit ist, spielt ihr Geltungsbereich keine Rolle, also lass ihn auf allen Site-Keys. Sie braucht weder Lesen, Erstellen noch Bearbeiten für ihre Arbeit; Verwalten ist die Berechtigung, die das Team führt.

Jetzt kann Dana den Rest des Onboardings Ana abnehmen: sie kann einen CI-Token ausgeben, die nächste Einstellung hinzufügen und Berechtigungen anpassen, alles, ohne durch einen Geltungsbereich ausgesperrt werden zu können.

3. Raj einladen, den Entwickler auf einem Produkt (Bearbeiten, eingeschränkt)

Lade Raj auf dieselbe Weise ein. Er besitzt den Shop, nicht den Blog, also:

  • Gewähr Bearbeiten (und Lesen, damit er sieht, was er bearbeitet). Bearbeiten lässt ihn den Key konfigurieren: seine Einstellungen, Secret-Rotation, gehostete Verifizierung und die Spiel- und White-Label-Anpassung des Keys.
  • Setz seinen Geltungsbereich auf bestimmte Site-Keys und wähl nur shop.bananaseed.com.

Lass Verwalten aus. Raj soll sein Produkt konfigurieren, nicht das Team führen. Mit Bearbeiten auf einen Key eingeschränkt bekommt er genau das: er kann die Aufgabe und den Skin des Shops justieren, und er kann den Blog, die Mitgliederliste oder die Tokens nicht anfassen.

Das ist die alltägliche Least-Privilege-Gewährung: eine Berechtigung (Bearbeiten), begrenzt durch einen Geltungsbereich (ein Key).

4. Mia einladen, die Managerin, die nur liest (Lesen)

Lade Mia ein und gewähr nur Lesen, auf allen Site-Keys. Lesen lässt sie jeden Key im Team öffnen und seine Statistik, Konfiguration und Audit-Logs ansehen und nichts davon ändern. Sie bekommt das teamweite Bild, das sie fürs Reporting braucht, ohne die Fähigkeit, versehentlich eine Einstellung zu bearbeiten oder ein Secret zu rotieren.

5. Jede Gewährung bestätigen

Lass jede Person sich anmelden und prüfen, dass das Team sich wie beabsichtigt verhält:

  • Dana sieht die Mitglieder- und Token-Steuerungen und kann sie ändern, aber die eigene Konfiguration eines Site-Keys zu bearbeiten ist nicht ihre Gewährung.
  • Raj kann shop.bananaseed.com öffnen und konfigurieren, sieht blog.bananaseed.com nicht und hat keine Mitglieder-Steuerungen.
  • Mia kann jeden Key öffnen und seine Statistik lesen, aber jede Bearbeiten-Steuerung fehlt.

Das ist der ganze Sinn des Modells: drei Personen, drei Jobs, drei verschiedene Reichweiten, keine davon hält mehr, als sie braucht. Auf Apex wird alles, was jede von ihnen tut, unter ihrer eigenen Identität im Team-Audit-Log aufgezeichnet.

Wohin als Nächstes

  • Füg eine CI- oder Service-Anmeldedatei statt einer Person mit einem Troop Access Token hinzu, das dieselben Berechtigungen und denselben Geltungsbereich trägt.
  • Setz Overrides einmal auf dem Team, sodass beide Keys die Marke erben.
  • Beobachte die Nutzung über beide Produkte auf der Statistik des Teams.

Siehe auch

Auf dieser Seite