Mejores prácticas de seguridad

Mejores prácticas: Planificar el nivel de exposición

Le recomendamos que responda a las siguientes preguntas antes de implantar un plan de seguridad para los clusters que cree con Kubernetes Engine:

• ¿Cuánta exposición a Internet desea que tengan los clusters?
• ¿Cómo planea exponer las cargas de trabajo internamente en su VCN y/o externamente en Internet?
• ¿Cómo planea escalar las cargas de trabajo?
• ¿Qué tipos de servicios de Oracle consumirá el cluster?

Una vez respondidas las preguntas anteriores, le recomendamos que tenga en cuenta las siguientes mejores prácticas:

• Mejores Prácticas: Creación de Clusters Privados

  Recomendamos que, si solo desea exponer las cargas de trabajo internamente a su VCN y no a Internet, cree clusters nativos de VCN con el punto final de API de Kubernetes en una subred privada. Estos clusters a veces se denominan clusters privados.

  Al configurar clusters privados, todos los componentes del plano de control (incluido el punto final de API de Kubernetes del cluster) se encuentran en un espacio de red privado de RFC 1918. Como resultado, el acceso es limitado y todo el tráfico permanece dentro de las redes de Oracle. Puede bloquear el acceso a la API de Kubernetes a una VCN específica.

  Si no utiliza clusters privados, el punto final de API de Kubernetes del cluster tiene una dirección IPv4 pública y todo el tráfico a la API (incluido el tráfico de los pools de nodos del cluster) pasa por el espacio de red público.

  Consulte Presentación de clusters de Kubernetes privados.

• Mejores prácticas: colocación de todas las aplicaciones en subredes privadas

  Recomendamos que, si desea reducir la exposición de un servicio a Internet, coloque las instancias informáticas de nodos de trabajador que ejecutan cargas de trabajo de aplicaciones en subredes privadas y configure equilibradores de carga para acceder a ellas.

  El aislamiento de instancias de servicio de Internet reduce la superficie de ataque de un servicio. La mayoría de las instancias de servicio no necesitan exposición directa a Internet.

  Consulte Configuración de recursos de red para despliegue y creación de clusters.

• Mejores prácticas: restricción del tráfico de cluster mediante grupos de seguridad de red

  Le recomendamos que defina reglas de seguridad en grupos de seguridad de red (en lugar de en listas de seguridad) para la VCN en la que desea crear y desplegar clusters.

  Kubernetes Engine crea las reglas de seguridad necesarias por defecto, pero puede cambiarlas para satisfacer sus requisitos específicos.

  Consulte Configuración de reglas de seguridad en grupos de seguridad de red y/o listas de seguridad.

Mejores prácticas: aplique parches de seguridad con regularidad

Le recomendamos que actualice periódicamente el sistema operativo que se ejecuta en los nodos de trabajador para aplicar los parches de seguridad más recientes.

Los nodos de trabajador de los clusters creados por Kubernetes Engine ejecutan una imagen de Linux reforzada.

Es importante mantener el sistema operativo del nodo de trabajador endurecido y seguro porque los servicios que se ejecutan en nodos de trabajador incluyen el tiempo de ejecución del contenedor, kubelet y kube-proxy.

Otra buena práctica es utilizar la referencia de Kubernetes de Center for Internet Security (CIS) para nodos de trabajador.

Consulte Creación de nodos de trabajador con propiedades actualizadas.

Mejores prácticas: utilice una combinación de políticas de red y grupos de seguridad de red (NSG) de Kubernetes

Le recomendamos que considere la posibilidad de implantar políticas de red de Kubernetes en combinación con grupos de seguridad de red de OCI (recomendado) y/o listas de seguridad.

Una combinación de políticas de red de Kubernetes (para proteger la comunicación de red en el nivel de pod) y NSG y/o listas de seguridad de OCI (para proteger la comunicación de red en el nivel de host) puede ofrecer la mejor estrategia de seguridad de red.

Consulte Network Security.

Mejores prácticas: uso de grupos de seguridad de red (NSG) junto con herramientas de infraestructura como código (como Terraform)

Recomendamos utilizar reglas de seguridad en grupos de seguridad de red (NSG) en lugar de en listas de seguridad, al implantar un controlador de equilibrio de carga junto con herramientas de infraestructura como código como Terraform,

Para utilizar Kubernetes a escala, normalmente utilizará herramientas de infraestructura como código como Terraform para realizar un seguimiento del estado de los recursos de infraestructura. Por ejemplo, para mantener la infraestructura en su estado original y previsto, normalmente ejecutará y volverá a ejecutar una configuración de Terraform. Sin embargo, se produce un posible conflicto para los servicios de Kubernetes de tipo LoadBalancer si el administrador-controlador-nube agrega o actualiza reglas de seguridad en la lista de seguridad que utiliza una subred. Los cambios en las reglas de seguridad de una lista de seguridad no se reflejan en la configuración de Terraform. Como resultado, la próxima vez que ejecute Terraform, los cambios realizados en las reglas de seguridad de la lista de seguridad se marcan como un "cambio" desde el estado original y se descartan al aplicar la configuración de Terraform. Sin las reglas de seguridad, las aplicaciones desplegadas en un cluster pueden fallar porque el equilibrador de carga o el equilibrador de carga de red que aprovisiona el servicio de tipo LoadBalancer no pueden servir tráfico ni comunicarse con nodos que alojan los pods de aplicación.

Puede configurar el administrador de controladores en la nube para que no gestione las reglas de seguridad de una lista de seguridad de subred o para que solo gestione reglas de seguridad de salida para el equilibrador de carga o el equilibrador de carga de red. Sin embargo, en ambos casos, debe configurar manualmente los puertos seleccionados cada vez que se despliegue un nuevo servicio en el cluster o abrir el rango de puertos de nodo por completo. Ninguna de las dos soluciones es ideal, ya que una implica trabajo manual en tiempo de ejecución y la otra introduce una posible vulnerabilidad de seguridad.

Para evitar la posibilidad de que el gestor de controladores en la nube mute un recurso de lista de seguridad agregando o actualizando reglas de seguridad, y esos cambios se descartan posteriormente al aplicar una configuración de Terraform, por lo tanto, recomendamos que el gestor de controladores en la nube utilice NSG. Las reglas de seguridad definidas para un NSG son recursos por derecho propio con sus propios OCID y son independientes del propio NSG. Dado que el cambio de reglas de seguridad de NSG no mutará el recurso de NSG en sí, no se descartarán cambios al aplicar una configuración de Terraform.

Para obtener más información, consulte Uso de la anotación oci.oraclecloud.com/security-rule-management-mode para gestionar reglas de seguridad en NSG y listas de seguridad.

Mejores prácticas: rotación regular de secretos y certificados

Le recomendamos que establezca tiempos de vida cortos para secretos, credenciales y certificados, y que automatice su rotación.

Mejores prácticas: ejecución de todas las aplicaciones como usuario sin privilegios

Le recomendamos que ejecute todas las aplicaciones como usuario sin privilegios. Esto también es un requisito en una serie de normas regulatorias.

La ejecución de aplicaciones como usuario sin privilegios garantiza que si un atacante aprovecha una vulnerabilidad (como una vulnerabilidad de ejecución remota de código), estén restringidas al acceso limitado otorgado al usuario sin privilegios. El atacante también encontrará más difícil escalar un ataque para obtener privilegios adicionales, para salir de un contenedor o para obtener acceso root a través de un error del núcleo.

Mejores prácticas: Tratar los contenedores como inmutables

Le recomendamos que defina los sistemas de archivos raíz de contenedor como de solo lectura. Si permite que las bibliotecas y los binarios del sistema de archivos raíz de un contenedor se actualicen, hace que todo el cluster sea vulnerable a ataques.

La naturaleza efímera de los contenedores proporciona importantes beneficios de seguridad. A medida que las aplicaciones y su entorno inmediato se despliegan y actualizan en su conjunto, los ataques persistentes en el sistema general son más difíciles. La prevención de la modificación del sistema de archivos raíz fortalece la seguridad, tanto mediante la reducción de la probabilidad de amenazas como mediante la reducción de su impacto potencial.

Mejores prácticas: Considere la posibilidad de descargar el procesamiento SSL en controladores de entrada o equilibradores de carga (si está permitido)

Recomendamos que, si la política de seguridad de red de su organización le ofrece flexibilidad para hacerlo, descargue el procesamiento SSL a controladores de entrada o equilibradores de carga.

Los controladores de entrada (por ejemplo, Traefik, código abierto NGINX) permiten enrutar de forma inteligente el tráfico HTTP/S que emana desde fuera del cluster a los servicios que se ejecutan dentro del cluster. El servicio Oracle Cloud Infrastructure Load Balancer soporta protocolos de cifrado de transporte (SSL y TLS) para cifrar datos en tránsito.

El tráfico cifrado se puede terminar en diferentes lugares de la red (por ejemplo, en el equilibrador de carga, en el recurso de entrada, en el pod). La política de seguridad de red de su organización dicta en última instancia cómo y dónde terminar las conexiones SSL. Por ejemplo, si la política de seguridad de red de su organización requiere un cifrado integral, el tráfico debe descifrarse en el pod. El descifrado del tráfico supondrá una carga adicional para el pod, ya que este tendrá que pasar ciclos estableciendo el protocolo de enlace inicial, y el procesamiento SSL/TLS hace un uso intensivo de la CPU. Por lo tanto, si la política de seguridad de red de su organización le ofrece flexibilidad para hacerlo, descargue el procesamiento SSL en el controlador de entrada o en el equilibrador de carga.

Mejores Prácticas para la Auditoría, el Registro y la Supervisión

Recomendamos que tenga en cuenta las siguientes mejores prácticas al activar la auditoría, el registro y la supervisión:

• Mejores prácticas: compruebe los logs con regularidad

  Recomendamos que compruebe regularmente tanto los logs de auditoría del servidor de API de Kubernetes como los logs de aplicación de las aplicaciones que se ejecutan en nodos de trabajador del cluster. La comprobación periódica de los logs permite identificar amenazas o vulnerabilidades en el cluster.

  Consulte Observación de clusters de Kubernetes.

• Mejores prácticas: activación del registro de auditoría

  Le recomendamos que active el registro de auditoría y guarde los logs de auditoría en un repositorio seguro para un análisis futuro en caso de compromiso.

  Consulte Visualización de logs de auditoría del servidor de API de Kubernetes

• Mejores prácticas: uso del registro basado en cluster de Kubernetes

  Recomendamos utilizar el registro basado en cluster de Kubernetes para registrar la actividad de los contenedores en un subsistema de registro central. La salida estándar y la salida de error estándar de cada contenedor en un cluster de Kubernetes se pueden ingerir (mediante un agente como Fluentd que se ejecuta en cada nodo) en herramientas como Elasticsearch y se pueden ver con Kibana.

  Consulte Arquitectura de registro en la documentación de Kubernetes.

• Mejores Prácticas: Supervisión de Componentes de Cluster

  Recomendamos que supervise contenedores, pods, aplicaciones, servicios y otros componentes del cluster mediante herramientas como Prometheus, Grafana y Jaeger.

• Mejores prácticas: registrar metadatos de tráfico de red y analizarlos regularmente

  Recomendamos que active los logs de flujo de VCN en el servicio Oracle Cloud Infrastructure Logging para capturar metadatos sobre el tráfico que fluye a través de una VCN, como la dirección IP y el puerto de origen y destino, junto con paquetes aceptados o descartados. Una vez capturado, analice los metadatos con regularidad para identificar la actividad sospechosa o inusual entre los recursos de la VCN, incluidos los pods. Consulte Supervisión de tráfico de red mediante logs de flujo de VCN de Oracle.

Consulte Observación de clusters de Kubernetes.

Mejores prácticas: uso de imágenes de contenedor pequeñas y seguras

Le recomendamos que cree imágenes de contenedor pequeñas y seguras que solo contengan los paquetes, bibliotecas y herramientas que necesita la aplicación del contenedor.

Un nuevo desarrollador a menudo comete el error de usar la imagen base, a pesar de que no necesitan la mayoría de los paquetes y bibliotecas en la imagen base. Recomendamos elegir imágenes más pequeñas que requieran menos espacio de almacenamiento. Una imagen más pequeña le ayuda a extraer y crear la imagen más rápido. Y con una imagen más pequeña, hay menos probabilidades de problemas de seguridad.

Para reducir aún más el tamaño de la imagen del contenedor, recomendamos que solo instale las herramientas necesarias para la aplicación del contenedor. No incluya herramientas de depuración en contenedores de producción.

Si las aplicaciones solo necesitan herramientas de red al inicio del pod, en lugar de poner herramientas explotables como curl en una imagen para aplicaciones de larga ejecución, le recomendamos que considere utilizar contenedores de inicialización independientes o entregar los datos mediante un método más nativo de Kubernetes (como ConfigMaps).

También recomendamos mantener las imágenes de contenedor actualizadas y buscar nuevas versiones tanto de la imagen base como de cualquier herramienta de terceros que instale.

Mejores prácticas: Limitar la exposición a credenciales

Recomendamos que no defina credenciales en el código de aplicación. En su lugar, utilice un almacén digital (como Oracle Cloud Infrastructure Vault) para almacenar y recuperar claves y credenciales digitales.

Mejores prácticas: utilice un token de autenticación adecuado para acceder al cluster

Recomendamos que utilice únicamente el token de autenticación generado por el comando en el archivo kubeconfig de un cluster cuando acceda al cluster con kubectl y el panel de control de Kubernetes. Cuando otros procesos y herramientas accedan al cluster, utilice un token de autenticación no específico del usuario para la autenticación.

Al configurar el archivo kubeconfig para un cluster, el archivo contiene por defecto un comando de la CLI de Oracle Cloud Infrastructure para generar un token de autenticación específico del usuario, con ámbito de cluster y de vida corta. El token de autenticación generado por el comando de la CLI es adecuado para autenticar usuarios individuales que acceden al cluster mediante kubectl y el panel de control de Kubernetes.

Sin embargo, el token de autenticación generado no es adecuado para autenticar los procesos y las herramientas que acceden al cluster, como las herramientas de integración y entrega continuas (CI/CD). Para garantizar el acceso al cluster, dichas herramientas requieren tokens de autenticación no específicos de usuario de larga duración. Una solución es utilizar una cuenta de servicio de Kubernetes.

Consulte Adding a Service Account Authentication Token to a Kubeconfig File.

Mejores prácticas: configure el acceso con menos privilegios al crear RoleBindings y ClusterRoleBindings

Recomendamos que solo defina Kubernetes RoleBindings y ClusterRoleBindings que incluyan el juego de permisos necesarios para realizar una función específica.

Por defecto, a los usuarios no se les asigna ningún rol (o clusterroles) de Kubernetes RBAC. Por lo tanto, antes de intentar crear un nuevo Role (o ClusterRole), debe tener asignado un Role (o ClusterRole) con privilegios adecuados. Por defecto, siempre se crean una serie de roles y clusters, incluido el cluster-admin (para obtener una lista completa, consulte Roles y enlaces de roles por defecto en la documentación de Kubernetes). El ClusterRole cluster-admin básicamente concede privilegios de superusuario. Un usuario al que se ha otorgado el ClusterRole cluster-admin puede realizar cualquier operación en todos los espacios de nombre de un cluster determinado.

Consulte Acerca de control de acceso y Kubernetes Engine (OKE).