Configurazione dei vincoli del contesto di sicurezza

Con i vincoli del contesto di sicurezza (o SCC, security context constraint), puoi controllare le azioni e l'accesso che può essere eseguito dai pod all'interno del tuo cluster Red Hat® OpenShift® on IBM Cloud®. Per ulteriori informazioni sugli SCC, consultare la Red Hat OpenShift documentazione.

Perché devo impostare dei vincoli relativi al contesto di sicurezza?
Come amministratore cluster, vuoi controllare cosa succede nel tuo cluster, specialmente le azioni che influiscono sulla sicurezza o sulla disponibilità del cluster. I vincoli del contesto di sicurezza possono aiutarti a controllare quali azioni e quale accesso sono disponibili per i pod nel tuo contenitore, come ad esempio l'utilizzo di contenitori privilegiati, di spazi dei nomi root, di reti host e di porte, di tipi di volume, di file system host, di autorizzazioni Linux come ID di gruppo o di sola lettura e altro.
Posso aggiungere anche utenti o gruppi di sistema agli SCC?
Per consentire agli utenti di accedere alle risorse del cluster, non utilizzare gli SCC. Invece, consulta Assegnazione dell'accesso al cluster per impostare le autorizzazioni di IBM Cloud IAM e dell'infrastruttura.
Per i gruppi di sistema come system:authenticated, questi gruppi sono già assegnati agli SCC. Puoi vedere quali gruppi sono assegnati a un SCC descrivendo l'SCC. Se modifichi l'SCC a cui è assegnato un gruppo di sistema, è possibile che si verifichino degli errori nei componenti predefiniti che appartengono al gruppo di sistema a causa della modifica delle autorizzazioni.
Ci sono SCC impostati di default?
Per impostazione predefinita, i cluster Red Hat OpenShift on IBM Cloud includono una serie standard di SCC Red Hat OpenShift. Inoltre, i cluster dispongono di SCC(IBM ) che assomigliano molto alle politiche di sicurezza dei pod ( Kubernetes ) dei cluster della comunità Kubernetes presenti su IBM Cloud Kubernetes Service. Questi SCC IBM sono inclusi per una portabilità migliorata con i pacchetti privati IBM Cloud come i Cloud Pak.
Quali SCC vengono applicati alle mie risorse per impostazione predefinita?
Se non specifichi un contesto di sicurezza, per impostazione predefinita viene applicato il vincolo del contesto di sicurezza Red Hat OpenShift restricted (o restricted-v2 in 4.11 e versioni successive). Per controllare il contesto di sicurezza di un pod, descrivi il pod e cerca l'annotazione SCC, come nel seguente esempio.
oc describe pod <pod_name>

Name:               <pod_name>
Namespace:          <project_name>
...
Annotations:        openshift.io/...
                    openshift.io/scc=restricted
...
Posso utilizzare invece le politiche di sicurezza dei pod di Kubernetes?
Num. Le Kubernetes Kubernetes (PSP) sono originariamente basate sugli SCC Red Hat OpenShift. Tuttavia, Red Hat OpenShift supporta solo gli SCC, non le PSP.

Gli SCC Red Hat OpenShift predefiniti sono più rigidi delle PSP predefinite nei cluster Kubernetes della community. Pertanto, le distribuzioni di applicazioni che vengono eseguite nei cluster Kubernetes della community potrebbero dover essere modificate per l'esecuzione in Red Hat OpenShift.

Personalizzazione dei vincoli del contesto di sicurezza (o SCC, Security Context Constraint)

Per creare, modificare, elencare, eliminare e gestire in altro modo i vincoli di contesto di sicurezza, consultare la Red Hat OpenShift documentazione. È inoltre possibile autorizzare utenti o gruppi ai vincoli del contesto di sicurezza predefinito utilizzando il controllo dell'accesso basato sul ruolo come clusterroles, clusterrolebindings, roles e rolebindings. È anche possibile utilizzare i sottocomandi oc adm policy, come oc adm policy add-scc-to-user, per gestire queste impostazioni. La versione oc è uguale a quella del cluster gestito.

Linee guida per l'assegnazione dell'accesso agli SCC

  • Autorizza specifici account di servizio all'SCC che deve essere utilizzato dai pod in esecuzione con tale account di servizio.
  • Se un account di servizio ha bisogno di accedere a più SCC, prendi in considerazione la creazione di ulteriori account di servizio in modo che tutti i pod in esecuzione in un account di servizio utilizzino lo stesso SCC.
  • Non autorizzare tutti gli utenti o tutti gli account di servizio ad utilizzare SCC diversi dagli SCC restricted (4.10 e versioni precedenti) o restricted-v2 (4.11 e versioni successive).
  • Non modificare l'autorizzazione SCC per gli account di servizio negli spazi dei nomi openshift-*. I componenti Red Hat OpenShift sono progettati per essere eseguiti in specifici SCC e potrebbero non operare correttamente in un SCC differente.

Vincoli del contesto di sicurezza (o SCC, security context constraint) Red Hat OpenShift predefiniti

I cluster Red Hat OpenShift on IBM Cloud vengono forniti, per impostazione predefinita, con i seguenti vincoli del contesto di sicurezza (o SCC, Security Context Constraint).

Non modificare le impostazioni di SCC IBM od Red Hat OpenShift, fatta eccezione per i campi priority, users o groups.

Valore predefinito Red Hat OpenShift vincoli del contesto di sicurezza
Nome SCC Descrizione
anyuid Nega l'accesso in modo analogo all'SCC restricted ma consente l'esecuzione degli utenti con qualsiasi UID e GID.
hostaccess Consente l'accesso a tutti gli spazi dei nomi host ma richiede comunque che i pod siano eseguiti con un UID e un contesto SELinux che sono assegnati allo spazio dei nomi.

Importante: concedere questo SCC solo ai pod affidabili che necessitano dell'accesso dall'host a spazi dei nomi, file system e ID di processo.
hostmount-anyuid Nega l'accesso in modo analogo all'SCC restricted ma consente il montaggio host e qualsiasi UID da un pod. Questo SCC viene utilizzato principalmente dal riciclatore di volumi persistenti.

Importante: concedere questo SCC solo ai pod che richiedono l'accesso al file system dell'host con qualsiasi UID, compreso l'UID 0.
hostnetwork Consente l'utilizzo di rete host e porte host ma richiede comunque che i pod siano eseguiti con un UID e un contesto SELinux che sono assegnati allo spazio dei nomi.

Importante: assegnare questo SCC solo ai pod che richiedono l'accesso alla rete dell'host.
node-exporter Concede l'accesso appropriato per l'esportatore di nodi Prometheus integrato.
nonroot Nega l'accesso in modo analogo all'SCC restricted ma consente l'esecuzione degli utenti con qualsiasi UID non root. L'utente o il manifest del runtime del contenitore devono specificare l'UID.
privileged Consente l'accesso a tutte le funzionalità privilegiate e dell'host, nonché la possibilità di operare come qualsiasi utente, qualsiasi gruppo, con qualsiasi impostazione di " fsGroup " e con qualsiasi contesto SELinux.

Importante: concedere questo SCC esclusivamente per l'amministrazione del cluster che richiede il massimo livello di accesso possibile.
restricted Nega l'accesso a tutte le funzioni host e richiede che i pod siano eseguiti con un UID e un contesto SELinux che sono assegnati allo spazio dei nomi. Questo è l'SCC più restrittivo e viene utilizzato per impostazione predefinita per gli utenti autenticati.
hostnetwork-v2 Simile a hostnetwork SCC, ma modificato per ridurre al minimo le differenze dal profilo Pod Security Standards Restricted.
nonroot-v2 Simile a nonroot SCC, ma modificato per ridurre al minimo le differenze dal profilo Pod Security Standards Restricted.
restricted-v2 Simile a restricted SCC, ma modificato per soddisfare il profilo Pod Security Standards Restricted.

Vincoli del contesto di sicurezza IBM predefiniti

I cluster Red Hat OpenShift on IBM Cloud vengono forniti, per impostazione predefinita, con i seguenti vincoli del contesto di sicurezza (o SCC, Security Context Constraint) IBM.

Non modificare le impostazioni di SCC IBM od Red Hat OpenShift, fatta eccezione per i campi priority, users o groups.

Vincoli del contesto di sicurezza IBM predefiniti
Nome SCC Descrizione
ibm-anyuid-hostaccess-scc Consente l'esecuzione dei pod con qualsiasi UID e GID, qualsiasi volume e l'accesso completo all'host.

Importante: concedere questo SCC solo ai pod che richiedono l'accesso completo all'host e alla rete.
ibm-anyuid-hostpath-scc Consente l'esecuzione dei pod con qualsiasi UID e GID e qualsiasi volume, compreso il percorso host.

Importante: concedere questo SCC solo ai pod che necessitano di accesso ai volumi dell' hostPath.
ibm-anyuid-scc Consente l'esecuzione dei pod con qualsiasi UID e GID ma impedisce l'accesso all'host.
ibm-privileged-scc Concede l'accesso a tutte le funzioni host privilegiate e consente l'esecuzione di un pod con qualsiasi UID e GID e qualsiasi volume.

Importante: concedere questo SCC esclusivamente per l'amministrazione del cluster che richiede il massimo livello di accesso possibile.
ibm-restricted-scc Nega l'accesso a tutte le funzioni host e richiede che i pod siano eseguiti con un UID e un contesto SELinux che sono assegnati allo spazio dei nomi. Questo SCC è l'SCC IBM più restrittivo.