Configuración de restricciones de contexto de seguridad

Con las restricciones de contexto de seguridad (SCC), puede controlar las acciones y el acceso que pueden realizar los pods del clúster de Red Hat® OpenShift® on IBM Cloud®. Para obtener más información sobre los SCC, consulte la Red Hat OpenShift documentación.

¿Por qué establezco restricciones de contexto de seguridad?
Como administrador del clúster, desea controlar lo que sucede en el clúster, especialmente las acciones que afectan a la seguridad y a la preparación del clúster. Las restricciones de contexto de seguridad le pueden ayudar a controlar las acciones y el acceso que tienen pods del contenedor, como el uso de contenedores con privilegios, espacios de nombres raíz, redes de host y puertos, tipos de volumen, sistemas de archivos de host, permisos de Linux, como solo lectura o ID de grupo, y más.
¿Puedo añadir también usuarios o grupos del sistema a los SCC?
Para el acceso de usuario a los recursos del clúster, no utilice las SCC. En su lugar, consulte Asignación de acceso de clúster para establecer los permisos de IBM Cloud IAM y de infraestructura.
Para grupos de sistemas, como por ejemplo system:authenticated, estos grupos ya están asignados a las SCC. Puede ver los grupos que están asignados una SCC describiendo la SCC. Si cambia la SCC a la que está asignado un grupo de sistemas, los componentes predeterminados que pertenecen al grupo de sistemas pueden experimentar errores debido al cambio en los permisos.
¿Hay algún SCC establecido por defecto?
De forma predeterminada, los clústeres de Red Hat OpenShift on IBM Cloud incluyen un conjunto estándar de Red Hat OpenShiftSCC . Además, los clústeres cuentan con SCC de tipo « IBM » que se asemejan mucho a las políticas de seguridad de los pods « Kubernetes » de los clústeres de la comunidad Kubernetes en IBM Cloud Kubernetes Service. Estas SCC de IBM se incluyen para mejorar la portabilidad con paquetes de IBM Cloud Private, Cloud Paks.
¿Qué SCC se aplican a mis recursos de forma predeterminada?
Si no especifica un contexto de seguridad, se aplica de forma predeterminada la restricción de contexto de seguridad Red Hat OpenShift restricted (o restricted-v2 en 4.11 y posteriores). Para comprobar el contexto de seguridad de un pod, describa el pod y busque la anotación SCC, como en el siguiente ejemplo.
oc describe pod <pod_name>

Name:               <pod_name>
Namespace:          <project_name>
...
Annotations:        openshift.io/...
                    openshift.io/scc=restricted
...
¿Puedo utilizar en su lugar las políticas de seguridad de los pods de Kubernetes?
Núm. Las políticas de seguridad de pod deKubernetes (PSP) se basan originalmente en Red Hat OpenShift SCC. Sin embargo, Red Hat OpenShift solo da soporte a SCC, no a PSP.

Las SCC de Red Hat OpenShift predeterminadas son más estrictas que los PSP predeterminados de los clústeres de Kubernetes de comunidad. Por tanto, posible que los despliegues de app que se ejecutan en clústeres de Kubernetes de comunidad se tengan que modificar para que se ejecuten en Red Hat OpenShift.

Personalización de restricciones de contexto de seguridad

Para crear, editar, enumerar, eliminar y gestionar de cualquier otra forma las restricciones de contexto de seguridad, consulte la Red Hat OpenShift documentación. También puede autorizar a los usuarios o grupos a las restricciones de contexto de seguridad predeterminadas utilizando el control de acceso basado en roles como, por ejemplo, clusterroles, clusterrolebindings, roles y rolebindings. También puede utilizar los submandatos oc adm policy, como oc adm policy add-scc-to-user, para gestionar estos valores. La versión de oc es la misma que la del clúster que se está gestionando.

Directrices para asignar acceso a SCC

  • Autorice cuentas de servicio específicas para el SCC que van a utilizar los pods que se ejecutan bajo esa cuenta de servicio.
  • Si una cuenta de servicio necesita acceso a varias SCC, considere la posibilidad de crear cuentas de servicio adicionales para que se espere que todos los pods que se ejecutan bajo una cuenta de servicio utilicen la misma SCC.
  • No autorice a todos los usuarios o a todas las cuentas de servicio a utilizar cualquier SCC que no sea restricted (4.10 y anterior) o restricted-v2 (4.11 y posterior) SCC.
  • No cambie la autorización de SCC para las cuentas de servicio en los espacios de nombres de openshift-*. Los componentes de Red Hat OpenShift están diseñados para ejecutarse bajo SCC específicos y es posible que no funcionen correctamente bajo un SCC diferente.

Restricciones predeterminadas de contexto de seguridad de Red Hat OpenShift

Los clústeres de Red Hat OpenShift on IBM Cloud vienen con las siguientes restricciones de contexto de seguridad de forma predeterminada.

No edite los valores existentes de las SCC de Red Hat OpenShift o de IBM, con la excepción de los campos priority, users o groups.

Restricciones de contexto de seguridad de Red Hat OpenShift predeterminadas
Nombre de SCC Descripción
anyuid Deniega el acceso de forma parecida a la SCC restricted, pero permite que se ejecuten usuarios con cualquier UID y con cualquier GID.
hostaccess Permite el acceso a todos los espacios de nombres de host, pero sigue siendo necesario que los pods se ejecuten con un UID y un contexto de SELinux que se asignan al espacio de nombres.

Importante: otorgue esta SCC solo a los pods de confianza que requieran acceso de host a espacios de nombres, sistemas de archivos e ID de proceso.
hostmount-anyuid Deniega el acceso de forma parecida a la SCC restricted, pero permite montajes de host y cualquier UID por parte de un pod. El reciclador de volúmenes persistentes es el principal usuario de esta SCC.

Importante: otorgue esta SCC solo a los pods que requieran acceso al sistema de archivos de host como cualquier UID, incluido el UID 0.
hostnetwork Permite el uso de redes de host y de puertos de host, pero sigue siendo necesario que los pods se ejecuten con un UID y un contexto de SELinux que se asignan al espacio de nombres.

Importante: otorgue esta SCC solo a los pods que requieran acceso a la red de host.
node-exporter Proporciona el acceso adecuado para el exportador de nodo Prometheus incorporado.
nonroot Deniega el acceso de forma parecida a la SCC restricted, pero permite que los usuarios se ejecuten con cualquier UID que no sea root. El usuario o el manifiesto del tiempo de ejecución del contenedor deben especificar el UID.
privileged Permite el acceso a todas las funciones privilegiadas y del host, así como la posibilidad de ejecutar procesos como cualquier usuario, cualquier grupo, con cualquier configuración de « fsGroup » y con cualquier contexto de SELinux.

Importante: Concede este SCC únicamente para la administración de clústeres que requiera el máximo nivel de acceso posible.
restricted Deniega el acceso a todas las características del host y requiere que los pods se ejecuten con un UID y un contexto de SELinux que se asignan al espacio de nombres. Es la SCC más restrictiva y se utiliza de forma predeterminada para los usuarios autenticados.
hostnetwork-v2 Es similar al hostnetwork SCC, pero se ha modificado para minimizar las diferencias con respecto al perfil Restricted de Pod Security Standards.
nonroot-v2 Es similar al nonroot SCC, pero se ha modificado para minimizar las diferencias con respecto al perfil Restricted de Pod Security Standards.
restricted-v2 Similar al restricted SCC, pero modificado para satisfacer el perfil Restricted de Pod Security Standards.

Restricciones predeterminadas de contexto de seguridad de IBM

Los clústeres de Red Hat OpenShift on IBM Cloud vienen con las siguientes restricciones de contexto de seguridad de IBM de forma predeterminada.

No edite los valores existentes de las SCC de Red Hat OpenShift o de IBM, con la excepción de los campos priority, users o groups.

Restricciones predeterminadas de contexto de seguridad de IBM
Nombre de SCC Descripción
ibm-anyuid-hostaccess-scc Permite que los pods se ejecuten con cualquier UID y GID, cualquier volumen y acceso completo al host.

Importante: otorgue esta SCC solo a los pods que requieran acceso completo al host y a la red.
ibm-anyuid-hostpath-scc Permite que los pods se ejecuten con cualquier UID y GID y con cualquier volumen, incluida la vía de acceso al host.

Importante: Otorgue esta SCC solo a los pods que requieran acceso a los volúmenes de hostPath.
ibm-anyuid-scc Permite que los pods se ejecuten con cualquier UID y GID, pero impide el acceso al host.
ibm-privileged-scc Otorga acceso a todas las características de host con privilegios, y permite que un pod se ejecute con cualquier UID y GID y cualquier volumen.

Importante: otorgue esta SCC solo para la administración del clúster que requiera el mayor acceso posible.
ibm-restricted-scc Deniega el acceso a todas las características del host y requiere que los pods se ejecuten con un UID y un contexto de SELinux que se asignan al espacio de nombres. Esta SCC es la SCC más restrictiva de IBM.