Kubernetes RBAC

Åtkomstkontrollen tillämpas på två vägar. Anrop till plattformens API avgörs av RBAC-tjänsten. Anrop direkt till ett klusters Kubernetes API-server avgörs av Kubernetes egen RBAC, som plattformen skriver utifrån samma roller och tilldelningar — så att en person eller tjänsteprincipal som loggar in på API-servern med sin plattformsidentitet får rättigheter som motsvarar dess roller.

Vad en roll blir

Varje åtgärd i plattformens katalog kan bära Kubernetes-regler; kernel/k8sChannel/read bär till exempel get, list och watch på plattformens egna resurser. En rolls rättigheter i Kubernetes är reglerna för de åtgärder i kontrollplanet som den ger, minus reglerna för dess NotActions; dataåtgärder skrivs inte in i Kubernetes. Inbyggda roller kan lägga till egna regler ovanpå: Owner, Contributor, Reader och de tre plattformsrollerna har regler för poddar, deployments, tjänster, jobb och liknande grundresurser.

• Inbyggda roller blir ClusterRoles, som plattformen skriver.
• Anpassade roller blir namnrymdsbundna Roles, bara i de namnrymder där de är tilldelade.

Se upp

En del av de här reglerna ger mer i Kubernetes än rollen ger i portalen:

• Ett skal i varje podd som bindningen omfattar (pods/exec): Owner, Contributor, Platform Owner, Platform Contributor, Apps Operator och Blueprints Operator. Apps Operator och Blueprints Operator har den eftersom deras filbläddring och terminaler når podden den vägen.
• Hemlighetsvärden (secrets), som Kubernetes lämnar ut till alla som får göra get på en Secret. Platform Owner och Platform Contributor får läsa och ändra varje Secret i varje namnrymd, även plattformens egen och kube-system. Varje roll vars åtgärder omfattar kernel/k8sChannel/readSecretMetadata — direkt eller genom ett jokertecken som */* eller kernel/* — får göra get, list och watch på Secrets i de namnrymder där den är bunden; Owner och Contributor är sådana roller.

Räkna med att en tilldelning av de här rollerna på roten, en boundary eller en resursgrupp innefattar de rättigheterna.

Vad en tilldelning blir

Ett aktivt just-in-time-beviljande skrivs som en tilldelning och tas bort när det löper ut eller återkallas. Anpassade roller binds aldrig på /: en bindning på roten gäller i varje namnrymd, även plattformens egen och kube-system, så den är förbehållen de inbyggda rollerna.

Användare och tjänsteprincipaler syns i Kubernetes som användaren oidc: följt av deras principal-ID, och grupper som en Kubernetes-grupp namngiven med gruppens ID. Prefixet är modulinställningen Rbac__Reconciler__OidcUsernamePrefix och måste stämma med API-serverns användarnamnsprefix. Installationsprogrammet skriver det en API-server behöver för att ta emot plattformsinloggningar i ConfigMap-objektet stackship-kubeapi-oidc; att föra över det till kontrollplanets noder är upp till dig:

kubectl -n stackship-system get configmap stackship-kubeapi-oidc -o yaml

Nekandetilldelningar

Kubernetes RBAC kan inte neka. En nekandetilldelning kan därför bara utelämna en rolls bindning från ett kluster, och det gör den bara när allt detta gäller:

• nekandet namnger den principal som bindningen gäller. Grupper expanderas inte: ett nekande för en användare låter de bindningar som användaren har genom en grupp vara kvar;
• nekandet gäller på bindningens område;
• nekandet omfattar varje åtgärd och varje dataåtgärd som rollen ger. En rolls jokertecken omfattas bara av samma eller ett bredare, så Owners */* kräver */* både bland nekandets åtgärder och bland dess dataåtgärder.

Allt mindre tillämpas av plattformens API men inte av Kubernetes: principalen behåller rollens rättigheter i Kubernetes. Aktiva just-in-time-beviljanden skrivs in i Kubernetes oavsett vilka nekanden som gäller för dem.

Se upp

Ett nekande som skapas i portalen har bara åtgärder i kontrollplanet, så det tar aldrig bort bindningen för en roll som har dataåtgärder — bland dem Owner, Contributor, Reader, Platform Owner, Platform Contributor, Apps Operator och Blueprints Operator. Den som nekas allt i portalen har ändå de rollernas fulla rättigheter i Kubernetes, även skalen och läsningen av Secrets ovan. För att ta bort dem i Kubernetes tar du bort rolltilldelningen — eller skapar nekandet via API:et eller CLI:t med dataåtgärder som också omfattar rollens, och namnger den principal som varje bindning gäller.

Behörighetstaket

Plattformen skriver de här objekten som en egen identitet, ServiceAccount-kontot stackship-iam-projector i stackship-system, bundet till en ClusterRole med samma namn — dess tak: varje regel som katalogen kan uttrycka. Kubernetes låter bara en identitet skriva en roll med regler som den själv har, så taket är det mesta plattformen någonsin kan ge, och plattformen kan inte själv vidga sitt tak.

När en version lägger till regler för en resurs som taket ännu inte omfattar måste en klusteradministratör vidga det en gång:

1. Öppna Livscykelhantering och fliken Efter uppgradering. Ett kluster med statusen Kräver en klusteradministratör visar vilka regler som saknas och vilka kommandon som ska köras.
2. Kör kommandona en gång med en kubeconfig som har cluster-admin.
3. Välj Tillämpa på alla kluster igen. Det körs med dina egna uppgifter och registreras på ditt konto; det är säkert att tillämpa igen.

Visa manifestet laddar ner hela uppsättningen objekt som ett kluster behöver, för granskning eller för att tillämpa för hand på ett nytt kluster. För att läsa det behövs rbac/projector/read och för att tillämpa det rbac/projector/apply, båda på roten.