Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Controller di ammissione per migliorare la sicurezza di Kubernetes

Chi utilizza Kubernetes ne conoscerà probabilmente le funzioni di sicurezza di base, ad esempio RBAC e le policy di rete. Questi strumenti sono molto utili per applicare regole di base che stabiliscono quali azioni possono essere svolte dai diversi utenti o servizi in un cluster.

Alcune volte, però, si rivelano necessarie policy più granulari rispetto a RBAC o alle policy di rete. O magari, si potrebbero voler effettuare controlli aggiuntivi per convalidare una risorsa prima di autorizzarla all’interno del cluster.

Ecco dove entrano in gioco i controller di ammissione di Kubernetes. I controller di ammissione offrono una soluzione altamente estendibile per lo svolgimento dei controlli di sicurezza che va molto oltre le regole di autenticazione, autorizzazione e sicurezza della rete applicate tramite altri strumenti di Kubernetes. Svolgono un ruolo centrale nel collegare Kubernetes a strumenti di sicurezza esterni in grado di fornire analisi più avanzate e funzionalità di compliance.

I controller di ammissione sono una funzione opzionale che potrebbe non essere necessaria per le configurazioni più semplici, protette adeguatamente da RBAC o dalle policy di rete. Per proteggere cluster più complessi e su larga scala, tuttavia, si rivelano una risorsa che vale la pena sfruttare.

Questo articolo definisce i controller di ammissione di Kubernetes, spiega come funzionano e analizza i processi di utilizzo tipici per la sicurezza.

Cosa sono i controller di ammissione in Kubernetes?

Un controller di ammissione di Kubernetes è un codice che valuta le richieste che arrivano al server API di Kubernetes e determina se autorizzarle o meno.

La valutazione avviene dopo che il server API ha già autenticato e autorizzato la richiesta, ma prima che questa venga accettata e applicata.

In altre parole, anche se il server API ha determinato la validità di una richiesta (in base a eventuali RBAC Roles e ClusterRoles configurati), i controller di ammissione la valutano e decidono se accettarla o meno in base al proprio set di regole.

Vantaggi dei controller di ammissione

I controller di ammissione offrono diversi importanti vantaggi in una strategia di sicurezza Kubernetes:

  • Doppio controllo delle richieste: I controller di ammissione fungono, da un certo punto di vista, da seconda linea di difesa contro le richieste non valide che potrebbero aver superato i controlli RBAC (ad esempio a causa di un errore di configurazione in una policy RBAC).
  • Flessibilità delle regole: I controller di ammissione possono valutare le richieste e applicare le regole in base a parametri che non possono essere configurati (almeno, non facilmente) attraverso RBAC. Questo è importante perché RBAC definisce le regole solo in base a identità e azioni. I controller di ammissione offrono invece più sfumature, ad esempio la possibilità di limitare la richiesta di risorse o impedire l’esecuzione di comandi su un container privilegiato.
  • Integrazioni con terze parti: Alcuni controller di ammissione abilitano i webhook. È possibile utilizzare i webhook per attivare azioni nei sistemi di sicurezza di terze parti. Ciò significa che i controller di ammissione offrono un modo per integrare gli strumenti di sicurezza esterni in Kubernetes senza dover effettivamente eseguire questi strumenti direttamente nell’API. Probabilmente, questa è la funzione più potente dei controller di ammissione.

Utilizzare i controller di ammissione

Ecco come si utilizzano i controller di ammissione in Kubernetes.

Abilitare i controller di ammissione nel cluster

Per utilizzare i controller di ammissione in Kubernetes, è prima necessario accertarsi che questa funzione sia abilitata nel file kube-apiserver.yaml del cluster in uso (che, nella maggior parte dei casi, si trova nella directory /etc/kubernetes/manifests/ nel master Kubernetes o nei nodi master).

Se è presente il flag –enable-admission-plugins, i controller di ammissione sono abilitati per il cluster.

Scegliere controller di ammissione specifici

Il flag –enable-admission-plugins può essere seguito da un elenco separato da virgole, ad esempio:

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition ,Priority,DefaultTolerationSeconds,DefaultStorageClass,StorageObjectInUseProtection ,PersistentVolumeClaimResize,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,RuntimeClass ,ResourceQuota

Questo elenco identifica i controller di ammissione specifici attivati per il cluster. La documentazione Kubernetes descrive dettagliatamente tutti i controller di ammissione disponibili.

Se il flag –enable-admission-plugins è presente ma non è seguito da un elenco, Kubernetes abilita un set predefinito di controller di ammissione. Nelle attuali versioni di Kubernetes, si tratta di:

  • NamespaceLifecycle
  • LimitRanger
  • ServiceAccount
  • TaintNodesByCondition
  • Priority
  • DefaultTolerationSeconds
  • DefaultStorageClass
  • StorageObjectInUseProtection
  • PersistentVolumeClaimResize
  • RuntimeClass
  • CertificateApproval
  • CertificateSigning
  • CertificateSubjectRestriction
  • DefaultIngressClass
  • MutatingAdmissionWebhook
  • ValidatingAdmissionWebhook
  • ResourceQuota

Quindi, è possibile utilizzare i controller di ammissione predefiniti o definire esplicitamente quali controller abilitare.

Disattivare i controller di ammissione

Se lo si desidera, è possibile disattivare esplicitamente i controller di ammissione utilizzando il flag –disable-admission-plugins=… nel file kube-apiserver.yaml.

Questo flag è utile se si utilizza il set di controller predefiniti ma si desidera disattivare alcuni controller all’interno del set.

Verificare i controller di ammissione attivi

Se non si è sicuri di quali siano i controller di ammissione attivi nel cluster, è possibile eseguire il seguente comando per ottenerne un elenco:

kube-apiserver -h | grep enable-admission-plugins

Configurare i controller di ammissione

Kubernetes applicherà automaticamente tutti i controlli di ammissione attivati per un cluster. Non è necessario creare ulteriori file di policy (come sarebbe per esempio necessario in RBAC).

Tuttavia, per alcuni controller di ammissione potrebbe essere necessario specificare i dettagli della configurazione. Per esempio, per utilizzare il controller EventRateLimit che limita il numero di richieste che il server API può accettare, è necessario creare un file di configurazione in formato YAML e puntare il server API su di esso utilizzando il flag –admission-control-config-file.

Il file di configurazione sarà simile al seguente:

apiVersion: eventratelimit.admission.k8s.io/v1alpha1 kind: Configuration limits: - type: Namespace qps: 50 burst: 100 cacheSize: 2000 - type: User qps: 10 burst: 50
Code language: PHP (php)

In questo file, qps sta per query al secondo e burst definisce quante query il server API accetterà prima di applicare il limite stabilito da qps. Quindi, un qps di 50 con un burst di 100 indica che il server accetterà fino a 100 query prima di iniziare ad applicare il limite qps di 50. I limiti sono definiti per tipi specifici di risorse (nell’esempio precedente, namespace e utenti).

Per maggiori dettagli sulla configurazione di controller di ammissione specifici, consultare la documentazione Kubernetes.

Creazione di controller di ammissione personalizzati con i webhook

Quando sono adeguatamente configurati, i diversi controller di ammissione integrati possono migliorare notevolmente molti aspetti della sicurezza dei cluster.

Tuttavia, come già menzionato, l’aspetto più importante dei controller di ammissione è la loro capacità di integrarsi con strumenti di sicurezza esterni attraverso i webhook.

Per esempio, si può utilizzare il controller ImagePolicyWebhook per collegare un server remoto. Per fare questo, è prima necessario accertarsi del fatto che ImagePolicyWebhook sia attivato in kube-apiserver.yaml.

Quindi, è necessario creare un file (lo chiameremo admission-config.yaml) che includa i dettagli della configurazione ImagePolicyWebhook che verrà utilizzata per collegarsi al server remoto. Puntare il server API su questo file con:

kube-apiserver --admission-control-config-file=admission-config.yaml

Lo stesso file admission-config.yaml dovrebbe contenere una stanza simile a questa:

apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: - name: ImagePolicyWebhook configuration: imagePolicy: kubeConfigFile: <path-to-kubeconfig-file> allowTTL: 50 denyTTL: 50 retryBackoff: 500 defaultAllow: true
Code language: HTML, XML (xml)

Sarà anche necessario un file kubeconfig separato per configurare il server remoto, ad esempio:

# clusters refers to the remote service. clusters: - name: name-of-remote-imagepolicy-service cluster: certificate-authority: /path/to/ca.pem # CA for verifying the remote service. server: https://images.example.com/policy # URL of remote service to query. Must use 'https'. # users refers to the API server's webhook configuration. users: - name: name-of-api-server user: client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use client-key: /path/to/key.pem # key matching the cert
Code language: PHP (php)

Se propriamente configurato, questo consentirà al server API di Kubernetes di collegarsi a un server remoto (ovvero il server remoto definito sopra) per prendere decisioni sull’ammissione. Di nuovo, la bellezza di questo approccio è la possibilità di definire le regole di ammissione esternamente, senza dover incorporare un qualunque motore di policy si decida utilizzare nel server API di Kubernetes (perché, onestamente, la configurazione del server API è già abbastanza complessa).

In breve, i controller di ammissione di Kubernetes sono una risorsa potente e, almeno per gli standard di Kubernetes, piuttosto facile da usare per aggiungere un ulteriore livello di sicurezza ai cluster. I controller di ammissione specifici che si scelgono possono variare in base ai workload e potrebbe essere o non essere necessario definire controller personalizzati utilizzando i webhook.

Ma bisognerà almeno abilitare i controller di ammissione predefiniti per ciascun cluster Kubernetes che si intende utilizzare per qualunque tipo di workload di produzione.