Protezione dell'infrastruttura (host) - Amazon EKS
RaccomandazioniAlternativeStrumenti e risorse

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Protezione dell'infrastruttura (host)

Per quanto sia importante proteggere le immagini dei container, è altrettanto importante salvaguardare l'infrastruttura che le gestisce. Questa sezione esplora diversi modi per mitigare i rischi derivanti dagli attacchi lanciati direttamente contro l'host. Queste linee guida devono essere utilizzate insieme a quelle descritte nella sezione Runtime Security.

Raccomandazioni

Utilizza un sistema operativo ottimizzato per l'esecuzione di contenitori

Prendi in considerazione l'utilizzo di Flatcar Linux, Project Atomic, RancherOS e Bottlerocket, un sistema operativo speciale di AWS progettato per l'esecuzione di container Linux. Include una superficie di attacco ridotta, un'immagine del disco verificata all'avvio e l'utilizzo di limiti di autorizzazione impostati. SELinux

In alternativa, utilizza l'AMI ottimizzata EKS per i nodi di lavoro Kubernetes. L'AMI ottimizzata per EKS viene rilasciata regolarmente e contiene un set minimo di pacchetti e binari del sistema operativo necessari per eseguire i carichi di lavoro containerizzati.

Consulta la specifica di build Amazon EKS AMI RHEL per uno script di configurazione di esempio che può essere usato per creare un'AMI Amazon EKS personalizzata in esecuzione su Red Hat Enterprise Linux utilizzando Hashicorp Packer. Questo script può essere ulteriormente sfruttato per creare EKS custom conformi a STIG. AMIs

Mantieni aggiornato il tuo sistema operativo Worker Node

Indipendentemente dal fatto che utilizzi un sistema operativo host ottimizzato per contenitori come Bottlerocket o un Amazon Machine Image più grande, ma comunque minimalista, come EKS ottimizzato AMIs, è consigliabile mantenere queste immagini del sistema operativo host aggiornate con le ultime patch di sicurezza.

Per l'ottimizzazione per EKS AMIs, controlla regolarmente il canale CHANGELOG e/o le note di rilascio e automatizza l'implementazione di immagini aggiornate dei nodi di lavoro nel tuo cluster.

Trattate la vostra infrastruttura come immutabile e automatizzate la sostituzione dei nodi di lavoro

Anziché eseguire aggiornamenti sul posto, sostituisci i tuoi dipendenti quando diventa disponibile una nuova patch o un aggiornamento. Questo può essere affrontato in un paio di modi. Puoi aggiungere istanze a un gruppo di scalabilità automatica esistente utilizzando l'AMI più recente mentre cordoni e dreni i nodi in sequenza fino a quando tutti i nodi del gruppo non siano stati sostituiti con l'AMI più recente. In alternativa, puoi aggiungere istanze a un nuovo gruppo di nodi mentre cordoni e svuoti in sequenza i nodi del vecchio gruppo di nodi fino alla sostituzione di tutti i nodi. I gruppi di nodi gestiti da EKS utilizzano il primo approccio e visualizzeranno un messaggio nella console per aggiornare i lavoratori quando sarà disponibile una nuova AMI. eksctlha anche un meccanismo per creare gruppi di nodi con l'AMI più recente e per isolare e drenare con eleganza i pod dai gruppi di nodi prima che le istanze vengano terminate. Se si decide di utilizzare un metodo diverso per sostituire i nodi di lavoro, si consiglia vivamente di automatizzare il processo per ridurre al minimo la supervisione umana, poiché probabilmente sarà necessario sostituire i lavoratori regolarmente man mano che ne vengono rilasciati di nuovi updates/patches e quando il piano di controllo viene aggiornato.

Con EKS Fargate, AWS aggiornerà automaticamente l'infrastruttura sottostante non appena gli aggiornamenti saranno disponibili. Spesso questa operazione può essere eseguita senza problemi, ma a volte un aggiornamento può causare la riprogrammazione del pod. Pertanto, ti consigliamo di creare distribuzioni con più repliche quando esegui l'applicazione come pod Fargate.

Esegui periodicamente kube-bench per verificare la conformità ai benchmark CIS per Kubernetes

kube-bench è un progetto open source di Aqua che valuta il cluster rispetto ai benchmark CIS per Kubernetes. Il benchmark descrive le migliori pratiche per proteggere i cluster Kubernetes non gestiti. Il benchmark CIS Kubernetes comprende il piano di controllo e il piano dati. Poiché Amazon EKS fornisce un piano di controllo completamente gestito, non tutti i consigli del benchmark CIS Kubernetes sono applicabili. Per garantire che questo ambito rifletta il modo in cui viene implementato Amazon EKS, AWS ha creato il benchmark CIS Amazon EKS. Il benchmark EKS eredita da CIS Kubernetes Benchmark con input aggiuntivi dalla community con considerazioni specifiche sulla configurazione per i cluster EKS.

Quando esegui kube-bench su un cluster EKS, segui queste istruzioni di Aqua Security. Per ulteriori informazioni, consulta Presentazione del benchmark CIS Amazon EKS.

Riduci al minimo l'accesso ai nodi di lavoro

Invece di abilitare l'accesso SSH, usa SSM Session Manager quando devi accedere in remoto a un host. A differenza delle chiavi SSH che possono essere perse, copiate o condivise, Session Manager consente di controllare l'accesso alle EC2 istanze utilizzando IAM. Inoltre, fornisce un audit trail e un registro dei comandi eseguiti sull'istanza.

A partire dal 19 agosto 2020, i gruppi di nodi gestiti supportano modelli personalizzati AMIs e di EC2 lancio. Ciò consente di incorporare l'agente SSM nell'AMI o installarlo mentre il nodo di lavoro viene avviato. Se preferisci non modificare l'AMI ottimizzata o il modello di avvio di ASG, puoi installare l'agente SSM con un DaemonSet as in questo esempio.

Policy IAM minima per l'accesso SSH basato su SSM

La policy gestita da AmazonSSMManagedInstanceCore AWS contiene una serie di autorizzazioni che non sono necessarie per SSM Session Manager/SSM RunCommand se stai solo cercando di evitare l'accesso SSH. In particolare, sono preoccupanti * le autorizzazioni ssm:GetParameter(s) che consentirebbero al ruolo di accedere a tutti i parametri in Parameter Store (inclusa SecureStrings la chiave AWS managed KMS configurata).

La seguente policy IAM contiene il set minimo di autorizzazioni per abilitare l'accesso ai nodi tramite SSM Systems Manager.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableAccessViaSSMSessionManager",
      "Effect": "Allow",
      "Action": [
        "ssmmessages:OpenDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:CreateControlChannel",
        "ssm:UpdateInstanceInformation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnableSSMRunCommand",
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ec2messages:SendReply",
        "ec2messages:GetMessages",
        "ec2messages:GetEndpoint",
        "ec2messages:FailMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:AcknowledgeMessage"
      ],
      "Resource": "*"
    }
  ]
}

Una volta implementata questa politica e installato il plug-in Session Manager, è possibile eseguire

aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

per accedere al nodo.

Nota

Potresti anche prendere in considerazione l'aggiunta di autorizzazioni per abilitare la registrazione di Session Manager.

Distribuisci i lavoratori su sottoreti private

Impiegando i lavoratori su sottoreti private, si riduce al minimo la loro esposizione a Internet, dove spesso hanno origine gli attacchi. A partire dal 22 aprile 2020, l'assegnazione di indirizzi IP pubblici ai nodi di un gruppo di nodi gestiti sarà controllata dalla sottorete in cui vengono distribuiti. In precedenza, ai nodi di un gruppo di nodi gestiti veniva assegnato automaticamente un IP pubblico. Se scegli di distribuire i nodi di lavoro su sottoreti pubbliche, implementa regole restrittive dei gruppi di sicurezza AWS per limitarne l'esposizione.

Esegui Amazon Inspector per valutare gli host in termini di esposizione, vulnerabilità e deviazioni dalle best practice

Puoi utilizzare Amazon Inspector per verificare eventuali accessi di rete non intenzionali ai tuoi nodi e le vulnerabilità nelle istanze Amazon sottostanti. EC2

Amazon Inspector può fornire dati CVE (Common Vulnerabilities and Exposures) per le tue istanze Amazon solo se EC2 l'agente Amazon EC2 Systems Manager (SSM) è installato e abilitato. Questo agente è preinstallato su diverse Amazon Machine Images (AMIs), incluso Amazon Linux AMIs ottimizzato per EKS. Indipendentemente dallo stato dell'agente SSM, tutte le EC2 istanze Amazon vengono analizzate per individuare eventuali problemi di raggiungibilità della rete. Per ulteriori informazioni sulla configurazione delle scansioni per Amazon EC2, consulta Scansione delle istanze Amazon EC2 .

Importante

Inspector non può essere eseguito sull'infrastruttura utilizzata per eseguire i pod Fargate.

Alternative

Corri SELinux

Nota

Disponibile su Red Hat Enterprise Linux (RHEL), CentOS, Bottlerocket e Amazon Linux 2023

SELinux fornisce un ulteriore livello di sicurezza per mantenere i container isolati l'uno dall'altro e dall'host. SELinux consente agli amministratori di applicare i controlli di accesso obbligatori (MAC) per ogni utente, applicazione, processo e file. Immaginatelo come un backstop che limita le operazioni che possono essere eseguite a risorse specifiche sulla base di una serie di etichette. Su EKS, SELinux può essere usato per impedire ai container di accedere alle rispettive risorse.

Le SELinux politiche relative ai container sono definite nel pacchetto container-selinux. Docker CE richiede questo pacchetto (insieme alle sue dipendenze) in modo che i processi e i file creati da Docker (o da altri runtime dei container) vengano eseguiti con un accesso limitato al sistema. I contenitori sfruttano l'container_tetichetta che è un alias di. svirt_lxc_net_t Queste politiche impediscono efficacemente ai container di accedere a determinate funzionalità dell'host.

Quando SELinux configuri per Docker, Docker etichetta automaticamente i carichi di lavoro container_t in base al tipo e assegna a ciascun contenitore un livello MCS univoco. Questo isolerà i contenitori l'uno dall'altro. Se hai bisogno di restrizioni più flessibili, puoi creare il tuo profilo in SElinux cui concedere a un contenitore le autorizzazioni per aree specifiche del file system. Questo è simile al PSPs fatto che è possibile creare profili diversi per contenitori/pod diversi. Ad esempio, puoi avere un profilo per i carichi di lavoro generali con una serie di controlli restrittivi e un altro per gli elementi che richiedono un accesso privilegiato.

SELinux for Containers dispone di una serie di opzioni che possono essere configurate per modificare le restrizioni predefinite. I seguenti valori SELinux booleani possono essere abilitati o disabilitati in base alle esigenze:

Booleano Predefinito Descrizione

container_connect_any

off

Consenti ai container di accedere alle porte privilegiate sull'host. Ad esempio, se disponi di un contenitore che deve mappare le porte su 443 o 80 sull'host.

container_manage_cgroup

off

Consenti ai contenitori di gestire la configurazione di cgroup. Ad esempio, un contenitore che esegue systemd avrà bisogno che questo sia abilitato.

container_use_cephfs

off

Consenti ai contenitori di utilizzare un file system ceph.

Per impostazione predefinita, i contenitori possono visualizzare /usr e read/execute leggere la maggior parte dei contenuti. /etc I file /var/lib/docker sottostanti /var/lib/containers hanno l'etichettacontainer_var_lib_t. Per visualizzare un elenco completo delle etichette predefinite, consulta il file container.fc.

docker container run -it \
  -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \
  centos:7 cat /host/repositories.json
# cat: /host/repositories.json: Permission denied

docker container run -it \
  -v /etc/passwd:/host/etc/passwd \
  centos:7 cat /host/etc/passwd
# cat: /host/etc/passwd: Permission denied

I file etichettati con container_file_t sono gli unici file scrivibili dai contenitori. Se si desidera che un volume mount sia scrivibile, è necessario specificare :z o alla :Z fine.

  • :zrietichetterà i file in modo che il contenitore possa leggere/scrivere

  • :Zrietichetterà i file in modo che solo il contenitore possa leggere/scrivere

ls -Z /var/lib/misc
# -rw-r--r--. root root system_u:object_r:var_lib_t:s0   postfix.aliasesdb-stamp

docker container run -it \
  -v /var/lib/misc:/host/var/lib/misc:z \
  centos:7 echo "Relabeled!"

ls -Z /var/lib/misc
#-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp
docker container run -it \
  -v /var/log:/host/var/log:Z \
  fluentbit:latest

In Kubernetes, la rietichettatura è leggermente diversa. Invece di far rietichettare automaticamente i file da Docker, puoi specificare un'etichetta MCS personalizzata per eseguire il pod. I volumi che supportano la rietichettatura verranno automaticamente rietichettati in modo da essere accessibili. I pod con un'etichetta MCS corrispondente potranno accedere al volume. Se hai bisogno di un isolamento rigoroso, imposta un'etichetta MCS diversa per ogni pod.

securityContext:
  seLinuxOptions:
    # Provide a unique MCS label per container
    # You can specify user, role, and type also
    # enforcement based on type and level (svert)
    level: s0:c144:c154

In questo esempio s0:c144:c154 corrisponde a un'etichetta MCS assegnata a un file a cui il contenitore può accedere.

Su EKS è possibile creare politiche che consentano l'esecuzione di contenitori privilegiati, come FluentD e creare SELinux una politica per consentirgli di leggere da /var/log sull'host senza dover rietichettare la directory host. I pod con la stessa etichetta saranno in grado di accedere agli stessi volumi host.

Abbiamo implementato esempi AMIs per Amazon EKS SELinux configurati su CentOS 7 e RHEL 7. Questi AMIs sono stati sviluppati per dimostrare implementazioni di esempio che soddisfano i requisiti di clienti altamente regolamentati.

avvertimento

SELinux ignorerà i contenitori in cui il tipo non è limitato.

Strumenti e risorse