Utilizzo di PodSecurityPolicy

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

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:
  - '*'

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.

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

Hai trovato utile questa pagina? Facci sapere cosa ne pensi:

Invia feedback per...

Kubernetes Engine