Hoppa till innehållet
Stackship-dokumentation English

PolicyerAnvändareMaskinöversatt

Regelreferens

Vad varje policyregel kontrollerar, vilka objekt och resurser den omfattar, vad den avvisar och vilket meddelande en avvisning har.

Tillåtna beräkningsplaner

Kontrolleras av plattformen när en resurs skapas, och när en ändring flyttar den till en annan plan, för:

  • appar, containerinstanser (varje komponents plan), PostgreSQL, SQL Server, Qdrant och Valkey.

En resurs som redan körs på en plan får behålla den, och kan ändras på andra sätt, även efter att en policy slutat tillåta planen; bara en flytt till en annan plan kontrolleras.

En avvisad begäran svarar 422 med koden compute_plan_not_allowed och ett meddelande som namnger planen, till exempel Compute plan 'large' is not allowed in this boundary: a boundary policy disallows it. Allowed plans: small, medium. Portalen visar meddelandet, och dess planväljare visar planer som policyerna inte tillåter som inaktiverade, med orsaken.

Om plattformen inte kan läsa boundaryns policyer avvisar den varje skapande och planbyte som regeln omfattar med 503 och koden compute_plan_policy_unavailable i stället för att tillåta dem. Försök igen om en stund.

Se upp

Funktioner kontrolleras inte. Funktionernas planväljare gråar ut planer som en policy inte tillåter, men en funktion som skapas eller ändras via API:t eller CLI:t får vilken plan som helst.

Så kombineras planer:

  • Ett plannamn i en policy gäller alla resurstyper. En API-post som anger en typ, till exempel valkey/small, gäller bara den typen.
  • Med flera tillämpade policyer med den här regeln måste en plan tillåtas av alla som säger något om resurstypen.
  • En policy som gäller men vars namn inte matchar någon plan av typen tillåter ingenting: varje skapande av den typen avvisas.
  • Policyns omfattning ignoreras: regeln gäller i alla boundaryns kluster.

Admission-regler

Obligatoriska etiketter, Tillåtna register och Förbjud taggen latest kontrolleras av Kubernetes i varje kluster där policyn är installerad. De kontrollerar:

  • Pods, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs och CronJobs,
  • när de skapas eller ändras,
  • i de namnrymder som är märkta med policyns boundary.

Det omfattar det som plattformen skapar där för dina resurser — arbetslasterna för appar, statiska webbappar, funktioner och containerinstanser, och de jobb som bygger appar, statiska webbappar och funktioner — inte bara det du själv driftsätter.

Objekt som redan finns kontrolleras inte igen förrän de ändras. En podd som måste skapas på nytt — efter en utrullning eller uppskalning, eller när en podd tas bort eller flyttas till en annan nod — kontrolleras, och bryter den mot regeln skapas den inte. En körande arbetslast kan alltså tappa kopior medan en policy som den bryter mot tillämpas. Kontrollera vad dina arbetslaster använder innan du tillämpar en ny regel.

Ett avvisat objekt skapas eller ändras inte, och avvisningen namnger policyn, till exempel Policy 'no-latest' (DisallowLatestTag) denied image nginx: it is tagged latest or carries no tag. Om själva kontrollen misslyckas avvisas objektet också.

Se upp

Admission-regler kräver Kubernetes 1.30 eller senare. I ett äldre kluster sparas policyn och skrivs till klustret, men tillämpar ingenting — och varken portalen eller API:t visar det. Fråga plattformens operatör vilken Kubernetes-version era kluster kör.

Obligatoriska etiketter

Varje kontrollerat objekt måste ha varje listad etikett. Med ett obligatoriskt värde måste etiketten ha exakt det värdet; med tomt värde duger vilket värde som helst. Etiketterna läses från själva objektet, så en Deployment behöver dem på Deploymenten och dess poddar på poddarna.

Avvisningar lyder Policy 'owner-label' (RequiredLabels) requires the label team. eller, med ett värde, … requires label team=web, found api (<unset> när etiketten saknas).

Tillåtna register

Varje avbildning för containrar och init-containrar måste vara ett av de listade prefixen eller fortsätta ett efter ett /. Avbildningen jämförs exakt som den står i podden:

Prefix Tillåts Avvisas
ghcr.io/acme ghcr.io/acme/web:1.4 ghcr.io/acme-tools/web:1.4
docker.io/library docker.io/library/nginx:1.27 nginx:1.27

Ett avslutande / på ett prefix ignoreras. Lista varje register som boundaryns arbetslaster använder, även registren för de avbildningar som plattformen kör åt dina resurser.

Avvisningar lyder Policy 'trusted' (AllowedRegistries) denied image nginx:1.27: it is not under ghcr.io/acme.

Förbjud taggen latest

Varje avbildning för containrar och init-containrar måste ha en uttrycklig tagg som inte är latest, eller en digest:

Avbildning Resultat
nginx:1.27 Tillåts
nginx@sha256:…, nginx:latest@sha256:… Tillåts — en digest tillåts alltid
nginx:latest Avvisas
nginx, registry:5000/api Avvisas — ingen tagg betyder latest

Varning

En funktion som byggs från kod uppladdad i portalen byggs av ett jobb som använder en avbildning taggad latest. Så länge regeln tillämpas i funktionens boundary avvisas de byggena.

Avvisningar lyder Policy 'no-latest' (DisallowLatestTag) denied image nginx:latest: it is tagged latest or carries no tag.