Lag en Kubernetes revisjonspolicy

Når Kubernetes popularitet øker, er Kubernetes revisjon en avgjørende kilde til data å integrere i din Kubernetes sikkerhetsstrategi. Det gir sikkerhets- og DevOps -teamene en fullstendig åpenhet i alle operasjoner som foregår i klyngen. Revisjonsloggingsfunksjonaliteten ble introdusert i Kubernetes 1.11. Revisjonslogger er en viktig del av å beskytte Kubernetes -klyngen din siden de registrerer hendelsene som å sette i gang en nodeport -tjeneste, slette navnefelt og lansere nye distribusjoner. Denne bloggen forklarer i detalj hva Kubernetes revisjon er og gir deg informasjon som hjelper deg i gang. Før vi går videre til revisjonspolitikk i Kubernetes, la oss først definere hva revisjon er.

Hva er revisjon i Kubernetes?

Ved hjelp av Kubernetes revisjon blir en klynges historie med hendelser fanget i en serie poster som er organisert kronologisk. Selve kontrollplanet, appene som bruker Kubernetes API, og brukerne, alle gir aktiviteter som klyngen reviderer.

Klyngeadministratorer kan bruke revisjon for å gi svar på noen spørsmål som hva som skjedde, og når det skjedde, som initierte det, hva som skjedde, hvor det ble observert, hvor det oppsto, og hvor det går som alle blir avslørt.

Levetiden til revisjonsregister begynner med kube-apiserver-komponenten. Hver forespørsel gir en revisjonshendelse på hvert trinn i behandlingen, som deretter blir behandlet i tråd med en policy og blir lagret til en backend. Politikken bestemmer hva som blir registrert og backendene opprettholder postene. To av de nåværende implementeringene av backend er loggfiler og webhooks.

Hver forespørsel kan plasseres i et bestemt stadium. Stadiene og deres beskrivelse er avbildet i følgende:

Hva er revisjonspolitikken i Kubernetes?

Revisjonspolicyen spesifiserer standardene for hendelsene som må rapporteres og dataene som må gis. Revisjonspolitisk objektformat er spesifisert av revisjonen.K8s.IO API Group. En liste over regler sammenlignes med en hendelse når den blir behandlet på en ordnet måte. Arrangementets revisjonsnivå avgjøres av den første samsvarsregelen.

Ingen, Metdt, Request og RequestResponse er revisjonsnivåene som er spesifisert.

En fil som inneholder policyen kan sendes til kube-apiserver ved hjelp av -audit-policy-fil-bryteren. Hvis flagget ikke er satt, er ingen hendelser registrert i det hele tatt. Regler for revisjonspolicyfilen må fylles ut. En policy anses som ulovlig hvis den ikke inneholder noen forskrifter.

Her er et eksempel på en revisjonspolicyfil for din hjelp. Her kan du se all informasjon som brukere, grupper, ressurser og andre ting.

Husk at revisjonslogger er samlet basert på den konfigurerte revisjonspolicyen før du prøver å forstå revisjonspolicyen som er gitt i det følgende. Hendelsene og informasjonen som må registreres er spesifisert av revisjonspolitikken. Den aller første samsvarende regelen i hierarkiet for reglene som er spesifisert i revisjonspolitikken, bestemmer revisjonsnivået for hendelsen.

Vedlagt er en komplett eksempler på revisjonspolicyfil som du kan referere til å forstå detaljene bedre.

Kubernetes revisjonspolicyfil for GKE -klynger begynner med reglene som beskriver hvilke hendelser som ikke skal logges på i det hele tatt. For eksempel spesifiserer denne regelen at nodens ressurser eller nodesstatus -ressurser ikke skal rapportere noen forespørsler som er fremsatt av Kubelets. Husk at hvis nivået ikke er noen matchende hendelser, skal rapporteres.

Retningslinjene inneholder en liste over regler som er spesielle forekomster etter listen over nivå ingen regler. Som et eksempel instruerer denne spesielle sakens regelen å logge de spesifikke forespørslene på metadatalivå.

En hendelse samsvarer med regelen hvis alle følgende er sanne:

• Ingen foregående regel i policyfilen samsvarer med hendelsen.
• En ressurs av hemmelighetene, konfigurasjonene eller tokenreviews -typene er gjenstand for forespørselen.
• Den forespørselshevede stadiet av samtalen dekkes ikke av arrangementet.

Policyfilen inneholder deretter en samling av generelle regler etter listen. Du må endre verdien av $ (kjent_apis) til verdien av kjente APIer for å se skriptets generelle regler. Etter substitusjonen vises det en regel som lyder som følger:

Du kan logge hver forespørsel på metadatnivå ved hjelp av en enkel revisjonspolicyfil.

Hva er revisjonslogger og hvorfor du bør konfigurere dem

Revisjonslogger er veldig nyttige i en Kubernetes -klynge for å spore og spore aktivitetene og endringer i forskjellige klyngressurser. Du kan finne ut hvem som utførte hva og når ved å aktivere revisjonen, som ikke er aktivert som standard.

Revisjonslogger fungerer som grunnlag for sikkerhet og etterlevelse og gir innsikt i aktivitetene som foregår i en Kubernetes -klynge. Du kan øyeblikkelig oppdage all uvanlig oppførsel som oppstår i klyngen din, for eksempel mislykkede påloggingsforsøk eller forsøk på å få tilgang til sensitive hemmeligheter, med riktig konfigurert revisjonslogging. Du kan samarbeide på tvers av siloer for raskt å svare på mistenkelige aktiviteter ved å bruke revisjoner. Implementering av klyngeherding og avbøtende enhver feilkonfigurasjon hjelper begge rutinemessig revisjon av hendelsesloggdataene.

Konklusjon

Vi lærte hva Kubernetes revisjonslogger nøyaktig er til og hvilket formål de brukes til. Vi lærte også hvorfor revisjon er avgjørende for sikkerheten til Kubernetes -klyngen din. Nødvendigheten av å slå på revisjonsloggene for din Kubernetes -klynge blir også diskutert. For din referanse ga vi en eksempler på revisjonspolicyfil og en detaljert forklaring av innholdet. Du kan henvise til denne artikkelen hvis du er ny på dette konseptet.