Utilizzo di PodSecurityPolicy

Beta

Questa è una versione beta della funzionalità PodSecurityPolicy in Google Kubernetes Engine. Questa non è coperta da SLA (accordo sul livello del servizio) o da norme relative al ritiro e potrebbe essere soggetta a modifiche non retrocompatibili.

Questa pagina spiega come utilizzare PodSecurityPolicy in Google Kubernetes Engine.

Panoramica

PodSecurityPolicy è una risorsa controller di ammissione che puoi creare per convalidare le richieste di creazione e aggiornamento dei pod sul tuo cluster. PodSecurityPolicy definisce un insieme di condizioni che i pod devono soddisfare per essere accettati dal cluster. Quando una richiesta di creazione o aggiornamento di un pod non soddisfa le condizioni di PodSecurityPolicy, la richiesta viene rifiutata e viene restituito un errore.

Per utilizzare PodSecurityPolicy, dovrai innanzitutto creare e definire i criteri che i pod nuovi o aggiornati devono soddisfare. Quindi, dovrai attivare il controller di ammissione PodSecurityPolicy, che convalida le richieste di creazione e aggiornamento dei pod rispetto ai criteri definiti.

Quando sono disponibili più PodSecurityPolicy, il controller di ammissione utilizza il primo criterio che consente la riuscita della convalida. I criteri sono in ordine alfabetico e il controller privilegia quelli non mutanti (che non modificano il pod) rispetto ai criteri mutanti.

PodSecurityPolicy è disponibile nei cluster GKE che eseguono Kubernetes 1.8.6 o versioni successive.

Prima di iniziare

Per preparare questa attività, procedi nel seguente modo:

• Assicurati di aver attivato l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Assicurati di aver installato Cloud SDK.
• Imposta l'ID progetto predefinito:

  gcloud config set project [PROJECT_ID]

• Se utilizzi cluster di zona, imposta la zona di calcolo predefinita:

  gcloud config set compute/zone [COMPUTE_ZONE]

• Se utilizzi cluster regionali, imposta l'area geografica di calcolo predefinita:

  gcloud config set compute/region [COMPUTE_REGION]

• Aggiorna gcloud alla versione più recente:

  gcloud components update

Nota: puoi eseguire l'override di queste impostazioni predefinite nei comandi gcloud utilizzando i flag operativi --project, --zone e --region.

• Assicurati di comprendere come utilizzare il controllo degli accessi basato sui ruoli in GKE.

Definizione di PodSecurityPolicy

Perché il controller PodSecurityPolicy possa convalidare e accettare i pod nel cluster, dovrai definire le risorse PodSecurityPolicy nel cluster.

I criteri PodSecurityPolicy specificano un elenco di restrizioni, requisiti e valori predefiniti per i pod creati nell'ambito del criterio. Alcuni esempi sono l'applicazione di restrizioni all'utilizzo di container con privilegi, volumi hostPath e networking host o l'impostazione predefinita di tutti i container per l'esecuzione con un profilo seccomp. Il controller di ammissione PodSecurityPolicy convalida le richieste a fronte dei criteri PodSecurityPolicy disponibili.

Il seguente esempio di PodSecurityPolicy, my-psp.yaml, impedisce semplicemente la creazione di pod con privilegi. Il criterio interessa anche diversi altri aspetti di controllo, come consentire l'accesso a tutti i volumi disponibili:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: my-psp
spec:
  privileged: false  # Prevents creation of privileged Pods
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

Nota: privileged: false non è sufficiente per impedire ai pod di eseguire operazioni con privilegi. Per restrizioni più complete, fai riferimento all'esempio di criterio con restrizioni in Criteri di esempio.

La specifica PodSecurityPolicy può garantire numerosi aspetti di controllo. Gli aspetti di controllo specificati in questo esempio, seLinux, supplementalGroups, runAsUser e fsGroup, sono impostati su RunAsAny, a indicare che qualsiasi valore valido per questi campi può essere utilizzato con questo criterio.

Per ulteriori informazioni sugli oggetti PodSecurityPolicy e sui relativi aspetti di controllo, consulta Che cos'è un criterio di sicurezza pod? e il riferimento per i criteri nella documentazione relativa a Kubernetes.

Per creare questa risorsa, utilizzi lo strumento a riga di comando kubectl:

kubectl apply -f my-psp.yaml

Per ulteriori esempi di configurazione degli oggetti PodSecurityPolicy, consulta Esempio nella pagina Criteri di sicurezza pod della documentazione relativa a Kubernetes.

Autorizzazione dei criteri

Gli account con il ruolo cluster-admin possono utilizzare il controllo degli accessi basato sui ruoli per creare un oggetto Role o ClusterRole che conceda ai criteri PodSecurityPolicy l'accesso agli account di servizio desiderato. Un oggetto ClusterRole concede autorizzazioni a livello di cluster e un oggetto Role concede autorizzazioni all'interno di uno spazio dei nomi definito dall'utente.

Ad esempio, il seguente ClusterRole, my-clusterrole.yaml, consente l'accesso al criterio PodSecurityPolicy my-psp, come indicato da verb: use:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: my-clusterrole
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - my-psp
  verbs:
  - use

Crea l'oggetto ClusterRole eseguendo il seguente comando:

kubectl apply -f my-clusterrole.yaml

Dopo aver creato un oggetto Role (o ClusterRole), lo associ agli account di servizio desiderati creando una risorsa RoleBinding (o ClusterRoleBinding).

Nell'esempio che segue, la risorsa RoleBinding, my-rolebinding.yaml, associa l'oggetto ClusterRole my-clusterrole agli account di servizio in uno spazio dei nomi specifico, my-namespace:

# Bind the ClusterRole to the desired set of service accounts.
# Policies should typically be bound to service accounts in a namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-rolebinding
  namespace: my-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: my-clusterrole
subjects:
# Example: All service accounts in my-namespace
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
# Example: A specific service account in my-namespace
- kind: ServiceAccount # Omit apiGroup
  name: default
  namespace: my-namespace

In questa risorsa RoleBinding:

• Il campo subjects specifica a quali account è associato l'oggetto ClusterRole.
• Il primo elemento subject è un gruppo, system:serviceaccounts, che comprende tutti gli account di servizio del cluster.
• Il secondo elemento subject è un singolo ServiceAccount, default, che specifica l'account di servizio predefinito nello spazio dei nomi.

Crea la risorsa RoleBinding eseguendo il seguente comando:

kubectl apply -f my-rolebinding.yaml

Per ulteriori informazioni su RBAC, consulta Utilizzo dell'autorizzazione RBAC.

Attivazione del controller PodSecurityPolicy

Per utilizzare il controller di ammissione PodSecurityPolicy, devi creare un nuovo cluster o aggiornare un cluster esistente con il flag --enable-pod-security-policy.

Avviso: se attivi il controller PodSecurityPolicy senza prima definire e autorizzare alcun criterio effettivo, nessun utente, controller o account di servizio potrà creare o aggiornare pod. Se utilizzi un cluster esistente, dovrai definire e autorizzare i criteri prima di attivare il controller.

Per creare un nuovo cluster con PodSecurityPolicy, esegui il seguente comando:

gcloud beta container clusters create [CLUSTER_NAME] --enable-pod-security-policy

Per aggiornare un cluster esistente:

gcloud beta container clusters update [CLUSTER_NAME] --enable-pod-security-policy

Disattivazione del controller PodSecurityPolicy

Per disattivare il controller PodSecurityPolicy esegui il seguente comando:

gcloud beta container clusters update [CLUSTER_NAME] --no-enable-pod-security-policy

Se disattivi il controller, il cluster non eseguirà più la convalida e l'assegnazione di valori predefiniti ai criteri esistenti, ma questi non vengono eliminati. Neanche le associazioni vengono eliminate.

Utilizzo di NetworkPolicy

Se utilizzi un criterio NetworkPolicy e disponi di un pod soggetto a un PodSecurityPolicy, crea un oggetto Role o ClusterRole RBAC che disponga dell'autorizzazione per utilizzare il criterio PodSecurityPolicy. Quindi, associa l'oggetto Role o ClusterRole all'account di servizio del pod. In questo caso non è sufficiente concedere autorizzazioni agli account utente. Per ulteriori informazioni, consulta Autorizzazione dei criteri.

Passaggi successivi

• Ulteriori informazioni sul controllo degli accessi basato sui ruoli.
• Scopri come proteggere il tuo cluster utilizzando la gestione di identità e accessi.