OpenShift - Seguridad

La seguridad de OpenShift es principalmente una combinación de dos componentes que maneja principalmente las restricciones de seguridad.

• Restricciones del contexto de seguridad (SCC)
• Cuenta de servicio

Restricciones del contexto de seguridad (SCC)

Básicamente se utiliza para la restricción de pod, lo que significa que define las limitaciones de un pod, en cuanto a las acciones que puede realizar y todas las cosas a las que puede acceder en el clúster.

OpenShift proporciona un conjunto de SCC predefinidos que el administrador puede utilizar, modificar y ampliar.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Si uno desea utilizar cualquier scc predefinido, puede hacerlo simplemente agregando el usuario o el grupo al grupo scc.

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

Cuenta de servicio

Las cuentas de servicio se utilizan básicamente para controlar el acceso a la API maestra de OpenShift, a la que se llama cuando se activa un comando o una solicitud desde cualquiera de las máquinas maestras o nodos.

Cada vez que una aplicación o un proceso requiera una capacidad que no sea otorgada por el SCC restringido, deberá crear una cuenta de servicio específica y agregar la cuenta al SCC respectivo. Sin embargo, si un SCC no se adapta a sus requisitos, entonces es mejor crear un nuevo SCC específico para sus requisitos en lugar de utilizar el que mejor se ajuste. Al final, configúrelo para la configuración de implementación.

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

Seguridad del contenedor

En OpenShift, la seguridad de los contenedores se basa en el concepto de cuán segura es la plataforma de contenedores y dónde se ejecutan los contenedores. Hay muchas cosas que entran en escena cuando hablamos de la seguridad de los contenedores y de lo que se debe cuidar.

Image Provenance - Existe un sistema de etiquetado seguro que identifica de forma exacta e incontrovertible el origen de los contenedores que se ejecutan en el entorno de producción.

Security Scanning - Un escáner de imágenes comprueba automáticamente todas las imágenes en busca de vulnerabilidades conocidas.

Auditing - El entorno de producción se audita periódicamente para garantizar que todos los contenedores se basan en contenedores actualizados y que tanto los hosts como los contenedores están configurados de forma segura.

Isolation and Least Privilege- Los contenedores se ejecutan con los recursos y privilegios mínimos necesarios para funcionar con eficacia. No pueden interferir indebidamente con el anfitrión u otros contenedores.

Runtime Threat Detection - Una capacidad que detecta amenazas activas contra aplicaciones en contenedores en tiempo de ejecución y responde automáticamente a ellas.

Access Controls - Los módulos de seguridad de Linux, como AppArmor o SELinux, se utilizan para hacer cumplir los controles de acceso.

Existen algunos métodos clave mediante los cuales se archiva la seguridad de los contenedores.

• Controlar el acceso a través de oAuth
• Mediante consola web de autoservicio
• Por Certificados de plataforma

Controlar el acceso a través de OAuth

En este método, la autenticación del acceso de control de API se archiva obteniendo un token seguro para la autenticación a través de los servidores OAuth, que viene incorporado en la máquina maestra OpenShift. Como administrador, tiene la capacidad de modificar la configuración del servidor OAuth.

Para obtener más detalles sobre la configuración del servidor OAuth, consulte el Capítulo 5 de este tutorial.

A través de la consola web de autoservicio

Esta función de seguridad de la consola web está incorporada en la consola web OpenShift. Esta consola asegura que todos los equipos que trabajan juntos no tengan acceso a otros entornos sin autenticación. El maestro multi-telnet en OpenShift tiene las siguientes características de seguridad:

• La capa TCL está habilitada
• Utiliza el certificado x.509 para la autenticación
• Asegura la configuración de etcd en la máquina maestra

Por Certificados de Plataforma

En este método, los certificados para cada host se configuran durante la instalación a través de Ansible. Como utiliza el protocolo de comunicación HTTPS a través de la API Rest, necesitamos una conexión segura TCL a diferentes componentes y objetos. Estos son certificados predefinidos, sin embargo, incluso se puede tener un certificado personalizado instalado en el clúster del maestro para acceder. Durante la configuración inicial del maestro, los certificados personalizados se pueden configurar anulando los certificados existentes usandoopenshift_master_overwrite_named_certificates parámetro.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Para obtener más detalles sobre cómo generar certificados personalizados, visite el siguiente enlace:

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

Seguridad de la red

En OpenShift, las redes definidas por software (SDN) se utilizan para la comunicación. El espacio de nombres de red se utiliza para cada pod del clúster, en el que cada pod obtiene su propia IP y un rango de puertos para obtener tráfico de red. Con este método, se pueden aislar los pods debido a que no se puede comunicar con los pods del otro proyecto.

Aislar un proyecto

El administrador del clúster puede hacer esto mediante lo siguiente oadm command desde CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Esto significa que los proyectos definidos anteriormente no pueden comunicarse con otros proyectos del clúster.

Seguridad de volumen

La seguridad del volumen claramente significa proteger el PV y el PVC de los proyectos en el clúster OpenShift. Hay principalmente cuatro secciones para controlar el acceso a los volúmenes en OpenShift.

• Grupos suplementarios
• fsGroup
• runAsUser
• seLinuxOptions

Grupos suplementarios: los grupos suplementarios son grupos regulares de Linux. Cuando un proceso se ejecuta en el sistema, se ejecuta con una ID de usuario y una ID de grupo. Estos grupos se utilizan para controlar el acceso al almacenamiento compartido.

Verifique el montaje NFS usando el siguiente comando.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Verifique los detalles de NFS en el servidor de montaje usando el siguiente comando.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

Se puede acceder a / opt / nfs / export mediante UID454265 y el grupo 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup significa el grupo del sistema de archivos que se utiliza para agregar grupos suplementarios de contenedores. El ID de grupo suplementario se usa para el almacenamiento compartido y fsGroup se usa para el almacenamiento en bloque.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser utiliza el ID de usuario para la comunicación. Se utiliza para definir la imagen del contenedor en la definición de pod. Se puede utilizar un solo usuario de ID en todos los contenedores, si es necesario.

Mientras se ejecuta el contenedor, el ID definido coincide con el ID del propietario en la exportación. Si el ID especificado se define en el exterior, se vuelve global para todos los contenedores del pod. Si se define con un grupo específico, se vuelve específico para un único contenedor.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265