Hur arbetslasttoken utfärdas

Var identiteterna finns

Managed Identity-tjänsten har ingen databas. Varje identitet är en konfidentiell klient i plattformens identitetsleverantör, med namnet mi- följt av resursens ID, med service account-token påslagna och ingenting annat. Klientens beskrivning anger resursens typ, namn, resursgrupp och boundary, och det är därifrån tjänsten läser var en identitet hör hemma. Identitetens principal-ID är klientens service account-användare.

Resursens ID är dess Kubernetes-UID för appar och funktionsnamnutrymmen, och ett ID som härleds ur boundary, resursgrupp och namn för container instances.

Tokenslutpunkten

Poddar hämtar token från tjänsten inne i klustret:

POST http://module-managedidentity.stackship-system:8080/api/identities/<resource-uid>/token

Operatorn lägger in adressen i arbetslastens poddar som STACKSHIP_IDENTITY_TOKEN_ENDPOINT, hämtad från sin inställning ManagedIdentity__TokenEndpoint. Installationsprogrammet sätter den till plattformens namnrymd. Utan den faller operatorn tillbaka på http://module-managedidentity.stackship-system.svc.cluster.local:8080/api/identities, vilket bara stämmer för en plattform i stackship-system. Att sätta ManagedIdentity__Enabled till false stoppar variablerna för appar och funktioner; container instances får dem ändå, så fort en komponent behöver identiteten.

Slutpunkten publiceras inte via plattformens API, och den avvisar anropare vars adress inte är en privat eller klusterintern adress.

Hur en podd bevisar vem den är

En podd har ingen autentiseringsuppgift för plattformen när den frågar — det är hela poängen med slutpunkten — så resursens UID i sökvägen är bara en adress, ingen hemlighet. Beviset är en Kubernetes service account-token som operatorn låter kubelet projicera in i podden:

• på /var/run/secrets/stackship.se/identity/token, angiven av STACKSHIP_IDENTITY_POD_TOKEN_PATH;
• utfärdad för audience stackship-managed-identity: följt av resursens UID, och giltig i tio minuter;
• monterad i varje container som får veta vilken identitet den ska använda.

Podden skickar den i huvudet X-Stackship-Pod-Token. Tjänsten låter plattformens kärna granska den mot Kubernetes API-server i det kluster där arbetslasten körs, för audience för den identitet som begärs — så att en podds token bara någonsin godtas för den egna resursens identitet — och kräver sedan att poddens namnrymd är namnrymden för identitetens resursgrupp.

Viktigt

Bindningen till audience hindrar en arbetslasts podd från att använda sitt bevis för en annan arbetslast. Den stänger inte ute personer som har rättigheter i resursgruppens namnrymd:

• Den som kan köra kommandon i arbetslastens poddar — Kubernetes pods/exec, som Owner, Contributor, Apps Operator, Blueprints Operator, Platform Owner och Platform Contributor har när de är tilldelade på resursgruppen eller högre — kan läsa beviset och hämta identitetens token.
• Den som kan skapa poddar i namnrymden — Owner, Contributor, Platform Owner och Platform Contributor, med direkt åtkomst till klustret — kan få en token utfärdad för vilken stackship-managed-identity:<uid>-audience som helst, och därmed få vilken identitet som helst i resursgruppen.

Behandla de rättigheterna som likvärdiga med att ha rollerna för varje identitet i resursgruppen.

Först då hämtar tjänsten en åtkomsttoken från identitetsleverantören och returnerar den. Identitetens klienthemlighet lämnar aldrig tjänsten på den här vägen.

Vad som avvisas

Varje avvisning är samma 404: ingen sådan identitet, inget bevis, ett bevis som inte godtas vid granskningen, en podd i en annan namnrymd, en anropare utanför klustret. Tjänstens logg anger vilket. När kärnan inte går att nå avvisar slutpunkten hellre än lämnar ut identiteter, så arbetslaster med hemligheter startar inte förrän den är tillbaka.

Att skapa och ta bort identiteter

Plattformen skapar en identitet när en app, ett funktionsnamnutrymme eller en container instance skapas, och tar bort den när resursen tas bort; operatorn skapar också en saknad identitet för en app eller ett funktionsnamnutrymme som den stämmer av, och en för varje S3-lagringskonto. Att skapa är idempotent: en identitet som redan finns för resursen återanvänds. Identiteten får ingen roll.