Nekandetilldelningar

En nekandetilldelning namnger principaler, åtgärder och ett område, och blockerar de åtgärderna för de principalerna där. Nekanden prövas före allt annat: ett matchande nekande avvisar anropet även när en roll — Owner, Platform Owner eller ett aktivt just-in-time-beviljande — skulle tillåta det.

Hur ett nekande gäller

Ett nekande blockerar ett anrop när allt detta stämmer:

• anroparen, eller en grupp som anroparen är direkt medlem i, finns bland dess nekade huvudkonton;
• varken anroparen eller någon av de grupperna finns bland dess undantagna huvudkonton;
• åtgärden finns bland de nekade åtgärderna och inte bland åtgärderna som undantas från nekandet;
• anropet sker på nekandets område — eller under det, när nekandet gäller underområden.

Nekade åtgärder följer samma regler för jokertecken som roller — se Åtgärder och dataåtgärder. Att neka apps/write nekar också apps/delete.

Skapa en nekandetilldelning

Du behöver rbac/members/write på boundaryn; Owner och Platform Owner har den.

1. I portalen på https://portal.example.com öppnar du Åtkomstkontroll (IAM), går till Nekandetilldelningar och väljer Lägg till.
2. Detaljer:
   • Namn (obligatoriskt, högst 128 tecken) och en valfri Beskrivning.
   • Område — ifyllt med boundaryn, /boundaries/<boundary-id>. För att neka inom en resursgrupp eller på en resurs förlänger du det: /boundaries/<boundary-id>/resourcegroups/web eller /boundaries/<boundary-id>/resourcegroups/web/resources/apps/shop.
   • Tillämpa på underområde (resursgrupper och resurser) — på som standard. Avslaget gäller nekandet exakt på området och inte under det.
3. Huvudkonton & åtgärder:
   • Nekade huvudkonton — sök och lägg till minst ett.
   • Undantagna huvudkonton (undantagna från denna nekande) — valfritt; principaler som nekandet aldrig får gälla, inte heller genom en grupp de tillhör.
   • Nekade åtgärder — minst en, från checklistan eller som ett mönster.
   • Undantagna från nekande (NotActions) — valfritt; åtgärder att ta bort ur de nekade, till exempel för att neka apps/* men behålla apps/read.
4. Välj Skapa.

Nekandet gäller inom en minut eller två.

Vilka som kan namnges

Om du inte är Platform Owner måste varje nekat och undantaget huvudkonto vara en användare som är medlem i boundaryns tenant; grupper, tjänstekonton och managed identities avvisas. En nekad principal som inte uppfyller det avvisas med "One or more principals are not members of this tenant.", en undantagen med "Excluded principal not a member of this tenant." En Platform Owner kan namnge vilken principal som helst. Plattformens egna tjänsteprincipaler kan aldrig namnges.

Dataåtgärder

Portalen listar bara åtgärder i kontrollplanet. Ett nekande kan också blockera dataåtgärder — att läsa hemlighetsvärden, loggar, terminaler — när det skapas via API:t eller CLI:t, med dataActions och notDataActions bredvid actions:

stsh iam deny create --file deny.json

{
  "name": "No secret values for contractors",
  "actions": ["secretvault/write"],
  "dataActions": ["secretvault/readSecrets"],
  "scope": "/boundaries/<boundary-id>",
  "principals": ["<user-principal-id>"],
  "applyToChildScopes": true
}

Varje nekande behöver minst en åtgärd i kontrollplanet under actions, även ett som främst gäller data.

Ta bort en nekandetilldelning

En nekandetilldelning kan inte ändras. För att ändra en skapar du det nya nekandet och tar bort det gamla: på fliken Nekandetilldelningar väljer du papperskorgen bredvid det och bekräftar med Ta bort. Åtkomst som nekandet blockerade kommer tillbaka, om en roll ger den.

Nekanden påverkar också vad plattformen skriver in i Kubernetes, men långt ifrån fullständigt: ett nekande som görs i portalen tar inte bort rättigheterna i Kubernetes för Owner, Contributor, Reader eller någon annan roll med dataåtgärder. En operatör kan läsa reglerna i Kubernetes RBAC.