Skydda en funktion med en token

En funktion med autentisering påslagen tar bara emot ett HTTP-anrop när det har en giltig åtkomsttoken från den identitetsleverantör du anger. För att ändra inställningen behöver du functions/write. Timerfunktioner påverkas inte: de har ingen publik rutt.

Slå på den

1. Öppna funktionen och dess flik Konfiguration, avsnittet Autentisering.
2. Slå på Enable JWT Authentication.
3. Issuer URL — utfärdaren exakt som den står i tokenernas anspråk iss. För plattformens egen identitetsleverantör är det https://auth.example.com/realms/stackship, utan snedstreck på slutet.
4. Audience — valfri. När du anger den måste en tokens anspråk aud innehålla den. Tokener från plattformens identitetsleverantör bär stackship-kubernetes-client.
5. Välj Save. Funktionen driftsätts om med den nya inställningen.

Varning

Med autentisering påslagen och Issuer URL tom avvisas varje anrop med 401: funktionen stänger hellre än betjänar vem som helst.

Vad som kontrolleras

Namnutrymmets proxy kontrollerar varje anrop innan det når funktionen, och funktionens körmiljö kontrollerar det igen. En token godtas när:

• den skickas i huvudet Authorization: Bearer <token>;
• dess signatur verifieras med en av utfärdarens nycklar, som plattformen hittar via <issuer>/.well-known/openid-configuration — så utfärdaren måste gå att nå från klustret;
• den är signerad med en asymmetrisk algoritm (RSA, RSA-PSS eller ECDSA med SHA-256, SHA-384 eller SHA-512); osignerade och HMAC-signerade tokener avvisas;
• dess iss är lika med Issuer URL och den har en exp som inte har passerat, med 60 sekunders marginal; en nbf, om den finns, måste också ha passerat;
• dess aud innehåller Audience, när en sådan är angiven.

Alla andra anrop besvaras med 401. Token bevisar bara vem som anropar; vad anroparen får göra avgör din kod.

Viktigt

Proxyn kontrollerar inte tokener på sökvägar som börjar med /_api, /healthz eller /readyz. En funktion vars rutt börjar med någon av dem, till exempel /healthzone, kontrolleras bara av sin körmiljö, och en egen avbild bara om den själv kontrollerar token. Arbetslaster i boundaryn kan också anropa en funktion direkt inuti klustret, utan att passera proxyn. Funktioner som byggs från portalen kontrollerar token på båda ställena; en egen avbild måste kontrollera den själv — se Vad avbilden måste göra.

Anropa en skyddad funktion

Ett skript eller en pipeline kan logga in som ett tjänstekonto — se Autentisera — och skicka sin token till funktionen:

TOKEN=$(curl -s https://auth.example.com/realms/stackship/protocol/openid-connect/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" | jq -r .access_token)

curl -H "Authorization: Bearer $TOKEN" "https://my-namespace.fn.apps.example.com/hello"

Samma anrop utan huvudet svarar 401, vilket är ett snabbt sätt att kontrollera att funktionen är skyddad.

Vem som anropar

När ett anrop godtas skickar proxyn vidare anroparen till funktionen i förfrågans huvuden:

Ett huvud utelämnas när token saknar anspråket. Proxyn tar först bort de här huvudena från varje inkommande förfrågan, på alla funktioner, så att en anropare inte kan sätta dem själv i ett anrop genom proxyn. Ett anrop som görs direkt inuti klustret passerar inte proxyn — se Vad som kontrolleras. I en Node.js-hanterare innehåller ctx.user anspråken i den token som körmiljön själv har verifierat.

Namnutrymmets standardvärden

Namnutrymmets Konfiguration → Autentisering har Tvinga autentisering, Standard autentisering aktiverad, Utfärdare-URL och Publik. Ingen av dem påverkar namnutrymmets funktioner i dag:

• Tvinga autentisering sparas inte.
• De andra inställningarna sparas, men varje funktion har sin egen autentiseringsinställning, och den är avslagen när funktionen skapas.

Slå på autentisering för varje funktion som behöver det.