Crea una politica di audit Kubernetes
Con l'aumentare della popolarità di Kubernetes, l'auditing di Kubernetes è una fonte cruciale di dati da incorporare nella tua strategia di sicurezza di Kubernetes. Dà ai team di sicurezza e DevOps una completa trasparenza in tutte le operazioni che si svolgono all'interno del cluster. La funzionalità di registrazione dell'audit è stata introdotta in Kubernetes 1.11. I registri di auditing sono una parte essenziale della protezione del cluster Kubernetes poiché registrano eventi come l'avvio di un servizio di porte di nodi, eliminare gli spazi dei nomi e l'avvio di nuove distribuzioni. Questo blog spiega in dettaglio cosa è l'auditing di Kubernetes e ti fornisce informazioni che ti aiutano a iniziare. Prima di passare alla politica di auditing a Kubernetes, definiamo prima cos'è il controllo.
Cosa sta controllando in Kubernetes?
Usando l'auditing di Kubernetes, la storia degli eventi di un cluster viene catturata in una serie di record organizzati in modo cronologicamente. Il piano di controllo stesso, le app che utilizzano l'API di Kubernetes e gli utenti, forniscono tutte attività che i cluster audit.
Gli amministratori del cluster possono utilizzare il controllo per fornire risposte ad alcune domande come ciò che è accaduto e quando si è verificato, che lo hanno iniziato, ciò che è accaduto, dove è stato osservato, dove è stato originato e dove sta andando tutti che sono tutti rivelati.
La durata della vita dei record di audit inizia con il componente Kube-Apiserver. Ogni richiesta fornisce un evento di audit in ogni fase di elaborazione, che viene quindi pre-elaborato in linea con una politica e viene salvato in un backend. La politica determina ciò che viene registrato e i backend mantengono i record. Due delle attuali implementazioni di backend sono file di registro e webhooks.
Ogni richiesta può essere inserita in una fase particolare. Le fasi e la loro descrizione sono rappresentate nel seguente:
| Nome d'arte | Descrizione in fase |
|---|---|
| Richiesta ricevuta | La richiesta viene ricevuta dal gestore dell'audit. |
| Responsabile | Sebbene il corpo di risposta non venga trasmesso, le intestazioni di risposta rimangono. |
| Responsabile | Nessun byte aggiuntivo viene trasferito una volta inviato il corpo di risposta. |
| Panico | La richiesta non è riuscita a causa di un errore del server interno. |
Qual è la politica di audit in Kubernetes?
La politica di audit specifica gli standard per gli eventi che devono essere segnalati e i dati che devono essere forniti. Il formato oggetto politico di audit è specificato dal controllo.K8S.gruppo API IO. Un elenco di regole viene confrontato con un evento quando viene elaborato in modo ordinato. Il livello di audit dell'evento è deciso dalla prima regola di abbinamento.
Nessuno, METDT, richiesta e richiesta Response sono i livelli di audit specificati.
| Nessuno | Gli eventi che soddisfano questo requisito non dovrebbero essere registrati. |
|---|---|
| Metadati | I corpi di richiesta e risposta non sono registrati; Solo le informazioni sulla richiesta (richiedendo utente, risorsa, verbo, ecc.). |
| Richiesta | I dati del corpo e degli eventi di richiesta sono registrati, ma non il corpo di risposta. |
| Richiedere risposta | Gli organi di richiesta e risposta, così come i metadati dell'evento, dovrebbero essere tutti documentati. Le richieste che non sono correlate alle risorse non sono coperte da questo. |
Un file che contiene la politica può essere passato a Kube-Apiserver utilizzando l'interruttore-Audit-Policy-file. Se il flag non è impostato, nessun evento è affatto registrato. Il campo delle regole del file della politica di audit deve essere riempito. Una politica è considerata illegale se non contiene regolamenti.
Ecco un esempio di un file di criteri di audit per il tuo aiuto. Qui, potresti vedere tutte le informazioni come utenti, gruppi, risorse e altre cose.
Ricorda che i registri di audit sono raccolti in base alla politica di audit configurata prima di tentare di cogliere la politica di audit che viene fornita di seguito. Gli eventi e le informazioni che devono essere registrati sono specificati dalla politica di audit. La prima regola corrispondente nella gerarchia delle regole specificate nella politica di audit determina il livello di audit dell'evento.
Allegato è un file completo di criteri di audit di esempio che è possibile fare riferimento a comprendere meglio i dettagli.
Il file della politica di audit di Kubernetes per i cluster GKE inizia con le regole che descrivono quali eventi non dovrebbero essere accettati affatto. Ad esempio, questa regola specifica che le risorse dei nodi o le risorse di Nodesstatus non dovrebbero segnalare alcuna richiesta di kubelet. Ricorda che se il livello non è nessuno, non dovrebbero essere segnalati eventi corrispondenti.
Il file della politica contiene un elenco di regole che sono istanze speciali dopo l'elenco delle regole di livello. Ad esempio, questa regola del caso speciale indica di registrare le richieste specifiche a livello di metadati.
Un evento corrisponde alla regola se tutte le seguenti sono vere:
- Nessuna regola precedente nel file della politica corrisponde all'evento.
- Una risorsa dei tipi di segreti, configurazioni o tokenreviews è oggetto della richiesta.
- La fase di richiesta della chiamata non è coperta dall'evento.
Il file della politica contiene quindi una raccolta di regole generali seguendo l'elenco delle regole del caso speciale. È necessario modificare il valore di $ (noto_apis) in valore delle API note per visualizzare le regole generali dello script. Dopo la sostituzione, appare una regola che si legge come segue:
È possibile registrare ogni richiesta a livello di metadati utilizzando un semplice file di criteri di audit.
Cosa sono i registri di audit e perché dovresti configurarli
I registri di audit sono molto utili in un cluster Kubernetes per tracciare e monitorare le attività e le modifiche a varie risorse del cluster. Puoi scoprire chi ha eseguito cosa e quando abilitando l'auditing, che non è abilitato per impostazione predefinita.
I registri di audit servono come base per la sicurezza e la conformità e forniscono informazioni sulle attività che si svolgono in un cluster di Kubernetes. È possibile individuare immediatamente qualsiasi comportamento insolito che si verifica nel cluster, come tentativi di accesso non riusciti o tentativi di accedere ai segreti sensibili, con registrazione di audit correttamente configurata. È possibile collaborare attraverso i silos per rispondere rapidamente alle attività sospette impiegando audit. L'implementazione di indurimento del cluster e mitigazione di qualsiasi errore di configurazione è entrambi aiutati da un controllo di routine dei dati del registro degli eventi.
Conclusione
Abbiamo imparato a cosa servono esattamente i registri di audit di Kubernetes e per quale scopo vengono utilizzati. Abbiamo anche imparato perché il controllo è cruciale per la sicurezza del tuo cluster Kubernetes. Viene inoltre discussa la necessità di accendere i registri di audit per il cluster Kubernetes. Per il tuo riferimento, abbiamo fornito un file di politica di audit di esempio e una spiegazione dettagliata del contenuto. Puoi fare riferimento a questo articolo se sei nuovo a questo concetto.