Er containerne dine sikre nok for produksjon?Beholdere gir utmerket isolasjon mellom applikasjoner, men feilkonfigurasjoner, sårbare bilder og usikre kjøretidsinnstillinger kan gjøre beholdere fra en sikkerhetsfordel til et ansvar. Denne veiledningen dekker sikkerhetspraksisen som produksjonsbeholdermiljøer krever.
Viktige takeaways
- Start med minimale bilder:Distroless og alpine bilder reduserer angrepsoverflaten med 90 % sammenlignet med full OS-bilder.
- Skann på alle trinn:Bygg, push, distribuer og kontinuerlig i registeret. Sårbarheter oppdages etter distribusjon.
- Kjør aldri som root:Rotbeholdere kan rømme til verten. Ikke-root-beholdere er inneholdt selv om kompromittert.
- Skrivebeskyttede filsystemer:Hvis beholderen ikke trenger å skrive, gjør filsystemet skrivebeskyttet for å forhindre skadelig programvare.
- Kjøretidsovervåking fanger opp hva skanningen går glipp av:Nulldagers utnyttelser, forsyningskjedeangrep og innsidetrusler krever gjenkjenning av kjøretid.
Bildesikkerhet
Bruk minimalt med basisbilder
Hver pakke i et beholderbilde er potensiell angrepsoverflate. Et typisk Ubuntu-bilde inneholder 100+ pakker; et distroless bilde inneholder bare programmets kjøretid. Bruk Google Distroless for Java, Python, Node.js og Go applikasjoner. Bruk Alpine (5MB) når du trenger et skall for feilsøking. Bruk aldri fullstendige OS-bilder (Ubuntu, Debian, CentOS) i produksjon – de inneholder hundrevis av unødvendige pakker med kjente sårbarheter.
Bygger i flere trinn
Bruk flertrinns dockerfiler for å skille byggeavhengigheter fra kjøretidsbilder. Byggestadiet inkluderer kompilatorer, pakkeadministratorer og utviklingsverktøy. Den siste fasen inneholder bare den kompilerte applikasjonen og minimale kjøretidsavhengigheter. Dette forhindrer byggeverktøy (som ofte har CVE-er med høy alvorlighetsgrad) fra å vises i produksjonsbilder.
Bildeskanning pipeline
- Byggetid:Skann i CI pipeline før du skyver til registret. Blokkbygg med kritiske sårbarheter.
- Register:Kontinuerlig skanning i ECR, ACR eller Harbor fanger opp nyoppdagede CVE-er i eksisterende bilder.
- Inngang:Kubernetes adgangskontrollører bekrefter bildeskanningsresultater før de tillater distribusjon.
- Kjøretid:Overvåk for unormal containeratferd som kan indikere utnyttelse av uopprettede sårbarheter.
Runtime Security
Beholderherding
| Innstilling | Anbefalt verdi | Hvorfor |
|---|---|---|
| runAsNonRoot | sant | Forhindrer beholderescape gjennom root-privilegier |
| readOnlyRootFilesystem | sant | Hindrer skadelig programvare fra å skrive til filsystemet |
| allowPrivilegeEscalation | usant | Hindrer prosesser fra å få ytterligere privilegier |
| muligheter | drop: ["ALL"] | Fjerner alle Linux-funksjoner, legg bare til det som trengs |
| secompProfil | RuntimeDefault | Begrenser systemanrop tilgjengelig for containeren |
| resources.limits | Sett CPU og minne | Forhindrer ressursmisbruk (crypto-mining, DoS) |
Kjøretidsovervåking med Falco
Falco overvåker containeradferd mot sikkerhetsregler og varsler om brudd. Standardregler oppdager: skall skapt inne i en beholder, sensitiv filtilgang (/etc/shadow, /etc/passwd), uventede nettverkstilkoblinger, rettighetseskaleringsforsøk, kjøring av pakkebehandler i produksjonsbeholdere og kryptogruveprosesser. Egendefinerte regler kan legges til for din spesifikke applikasjonsatferd.
Supply Chain Security
Bildesignering og verifisering
Signer beholderbilder ved byggetidspunkt med cosign (Sigstore) eller Docker Content Trust. Bekreft signaturer ved distribusjon gjennom Kubernetes opptakskontrollere. Dette sikrer at bare bilder bygget av CI/CD-pipelinen din kan distribueres – og forhindrer forsyningskjedeangrep der angripere skyver skadelige bilder til registeret ditt.
Programvareliste (SBOM)
Generer SBOM-er for hvert containerbilde ved å bruke Syft eller Trivy. En SBOM viser hver komponent (OS-pakker, biblioteker, avhengigheter) i bildet. Når en ny sårbarhet avsløres, kan du umiddelbart identifisere hvilke bilder som er berørt uten å skanne alt på nytt. SBOM-er kreves i økende grad av forskrifter og bedriftskunder.
Hvordan Opsio sikrer beholdere
- Bildeledning:Vi implementerer skanning, signering og håndheving av retningslinjer på tvers av livssyklusen for beholderbildet.
- Kjøretidssikkerhet:Vi distribuerer og administrerer Falco/Sysdig for kontinuerlig overvåking av containerkjøring.
- Kubernetes herding:Vi hardner klyngekonfigurasjoner i henhold til CIS-standarder med løpende overvåking av samsvar.
- Hendelsesvar:Vårt SOC-team reagerer på containersikkerhetshendelser med inneslutning og rettsmedisinsk kapasitet.
Ofte stilte spørsmål
Er containere sikrere enn virtuelle datamaskiner?
Beholdere gir isolasjon på prosessnivå gjennom Linux navnerom og cgroups, mens VM-er gir isolasjon på maskinvarenivå gjennom hypervisorer. VM-er har sterkere isolasjonsgrenser. Beholdere tilbyr raskere distribusjon og mindre angrepsoverflate (ved bruk av minimale bilder). I praksis er riktig konfigurerte beholdere med kjøretidssikkerhetsovervåking sikre nok for de fleste produksjonsarbeidsbelastninger. Svært sensitive arbeidsbelastninger kan dra nytte av VM-nivåisolasjon eller containersandboxing (gVisor, Kata Containers).
Hva er den største containersikkerhetsrisikoen?
Kjøre containere som root med ubegrensede muligheter. En rotbeholder med alle funksjoner kan flykte til vertssystemet, få tilgang til andre beholdere, vertsressurser og potensielt Kubernetes API-serveren. Løsningen er enkel: sett runAsNonRoot: true, slipp alle funksjoner og bruk skrivebeskyttede filsystemer. Disse tre innstillingene eliminerer det meste av containersikkerhetsrisikoen.
Hvordan håndterer jeg hemmeligheter i containere?
Bak aldri hemmeligheter inn i beholderbilder eller send dem som miljøvariabler (synlig i prosessoppføringer og logger). Bruk ekstern hemmelig administrasjon: HashiCorp Vault med sidevogninjeksjon, AWS Secrets Manager med ECS/EKS integrasjon, eller Azure Key Vault med CSI-driver. Hemmeligheter bør injiseres under kjøring og bare lagres i minnet, aldri på disk.