Mejores prácticas para administrar Secrets en Kubernetes

Kubernetes usa objetos secretos, llamados Secrets, para almacenar tokens OAuth, claves de Secure Shell (SSH), contraseñas y otros datos secretos. Kubernetes Secrets nos permite mantener los datos confidenciales separados del código de nuestra aplicación, ya que se crean por separado de los pods. Esta separación, junto con una configuración adecuada del control de acceso basado en roles (RBAC), reduce las posibilidades de que el Secret quede expuesto —y posiblemente sea explotado— al interactuar con los pods, lo que aumenta la seguridad.

Aunque Kubernetes Secrets ayuda a prevenir la exposición accidental de datos, quizá no proteja los datos del clúster frente a ciberataques maliciosos. Por ejemplo, un usuario no autorizado con permisos para acceder al clúster etcd puede acceder a todos nuestros Kubernetes Secrets, por lo que debemos administrarlos con cuidado para garantizar su seguridad.

En este artículo, exploraremos las mejores prácticas para administrar Secrets en Kubernetes. Consulta nuestro artículo sobre seguridad de Kubernetes para conocer más riesgos de seguridad y mejores prácticas.

Cómo funcionan Kubernetes Secrets

Kubernetes Secrets permite almacenar datos en un objeto secreto, al que luego pueden acceder o que pueden modificar los clientes de Kubernetes. Un Secret es un par clave-valor que incluye un ID de Secret e información de autenticación. Kubelet usa el ID de Secret para identificar las credenciales que debe proporcionar a un contenedor de aplicación al crear un pod.

Kubelet se ejecuta en cada nodo de un clúster y administra los pods y sus contenedores. Los pods solo pueden acceder a los Secrets si forman parte explícita de un volumen montado o cuando kubelet extrae una imagen para usarla en un pod.

El servidor de API de Kubernetes almacena los Kubernetes Secrets. Solo pueden acceder a ellos usuarios específicos con permiso para acceder al servidor de API de Kubernetes. El servidor de API de Kubernetes es un único punto de falla para nuestra aplicación, por lo que debemos mantener nuestros datos protegidos.

Kubernetes Secrets:

• Ofrece una forma segura de compartir datos de configuración entre un controlador y sus trabajadores, por ejemplo, entre kubelet y un pod

• Ofrece una alternativa para almacenar datos confidenciales en el clúster de Kubernetes, como las credenciales para acceder a aplicaciones externas

• Ofrece una forma práctica de crear nuevos recursos en nuestro clúster de Kubernetes, como implementaciones o espacios de nombres

Mejores prácticas para Kubernetes Secrets

Los Secrets, como claves, contraseñas, tokens y otros valores de configuración, deben almacenarse correctamente. Si nuestro clúster de Kubernetes se ve comprometido, los Secrets deben seguir protegidos. Un atacante no debería poder explotarlos para comprometer datos confidenciales, crear una botnet o controlar servidores (C2).

Estas son algunas técnicas que nos ayudan a mantener protegidos los Kubernetes Secrets:

1. Habilitar el cifrado en reposo

2. Configurar reglas de RBAC

3. Cifrar los datos de etcd

4. Usar un almacén centralizado de Secrets para facilitar la administración

Habilitar el cifrado en reposo

Los datos de Kubernetes Secret se codifican en formato base64 y se almacenan como texto sin formato en etcd. Etcd es un almacén de clave-valor que sirve como almacenamiento de respaldo para el estado del clúster de Kubernetes y los datos de configuración. Almacenar Secrets como texto sin formato en etcd es riesgoso, ya que los atacantes pueden comprometerlos fácilmente y usarlos para acceder a sistemas.

La base de datos etcd no está cifrada de forma predeterminada, así que debemos cifrar los datos de Secret en reposo para evitar que la información confidencial que contienen caiga en manos de un atacante. Un atacante con acceso al sistema de archivos puede leer los Secrets desde el archivo.

Además, Kubernetes ofrece una función de cifrado en reposo que nos permite usar la API de Kubernetes para cifrar Secrets antes de almacenarlos en etcd. También podemos usar proveedores de cifrado, como KMSConfiguration, IdentityConfiguration, SecretboxConfiguration y AESConfiguration para proteger nuestros Secrets en reposo.

Un clúster de Kubernetes tiene varios nodos, cada uno con credenciales únicas para las operaciones de cifrado y descifrado. El objeto EncryptionConfiguration especifica el material de claves para las operaciones de cifrado y descifrado de cada nodo. La configuración de estos proveedores de cifrado se encuentra en el objeto EncryptionConfiguration, que permite cifrar Secrets localmente con una clave administrada de forma local.

Configurar reglas de RBAC

Cifrar Kubernetes Secrets en reposo es solo una parte de lo que se necesita para mantenerlos protegidos. También debemos controlar el acceso a los Secrets mediante reglas de RBAC para Kubernetes. La política de seguridad que autoriza el acceso a los Secrets puede basarse en tareas, tiempo o roles.

Kubernetes Secrets y las reglas de RBAC funcionan en conjunto, ya que uno de los motivos principales de la existencia de los objetos Kubernetes Secret es otorgar un acceso de RBAC distinto al que otorgaríamos para ConfigMap.

Podemos usar el objeto ClusterRoles para definir las acciones que un usuario puede realizar en un clúster, y un rol para definir las acciones que puede realizar dentro de un espacio de nombres. RBAC restringe la creación, eliminación y modificación de Secrets a usuarios específicos. Por ejemplo, podemos establecer una política que prohíba a los desarrolladores crear Secrets para un espacio de nombres determinado, pero no para los demás.

El marco de RBAC integrado de Kubernetes nos permite aplicar el principio de mínimo privilegio (PoLP) para restringir el acceso de usuarios o programas únicamente a los recursos o la información necesarios para realizar las tareas asignadas o funcionar correctamente. Esto ayuda a garantizar que solo las cuentas y los contenedores con privilegios tengan acceso a los Secrets. Si un atacante compromete un componente, el PoLP ayuda a evitar que escale sus permisos y comprometa otros componentes.

Cifrar los datos de etcd

Como solo necesitamos permiso para acceder al clúster etcd para acceder a los Secrets, debemos ser diligentes al proteger los datos confidenciales, por ejemplo, mediante la rotación automática de claves, información sobre su antigüedad y registros de auditoría. La mejor manera de hacerlo es evitar que estos datos estén disponibles en etcd. El controlador de almacenamiento predeterminado de etcd es local, y las claves de cifrado se almacenan localmente en el archivo de configuración. Esto puede hacer que sean vulnerables al malware u otras amenazas maliciosas.

Una forma de reforzar la seguridad de los datos de etcd es cifrar los Secrets antes de almacenarlos. Debemos usar un proveedor de cifrado, como un servicio de administración de claves (KMS), para almacenar nuestras claves y Secrets. Cabe señalar que la mayoría de los proveedores de Kubernetes administrado cifran de forma predeterminada el almacenamiento de Secrets en etcd cuando se crea un clúster, lo que ayuda a proteger nuestros datos de etcd.

Otro método de seguridad consiste en permitir el acceso a etcd únicamente al servidor de API. Solo debemos permitir que los nodos que requieren acceso usen los clústeres etcd. Podemos otorgar acceso a etcd mediante el servidor de API de Kubernetes y conceder permisos de lectura y escritura solo a usuarios o grupos específicos.

Usar un almacén centralizado de Secrets para facilitar la administración

Kubernetes Secrets son fundamentales para el funcionamiento de nuestra aplicación y podemos almacenarlos en varias ubicaciones. Cuando almacenamos Secrets en muchos lugares, protegerlos se vuelve difícil, especialmente si debemos administrarlos en varios clústeres o si tenemos una combinación de pares de claves públicas y privadas. Sin un sistema centralizado para administrar Secrets, estos quedan dispersos en distintas ubicaciones, lo que aumenta la superficie de ataque para usuarios no autorizados.

La administración centralizada de Secrets ofrece muchas ventajas, especialmente cuando se usan en varias instancias. Una solución de administración centralizada brinda una vista unificada del panorama de seguridad de Kubernetes. Podemos administrar fácilmente los Secrets, el control de acceso y las auditorías; además, un registro de auditoría central ofrece información sobre eventos de seguridad críticos.

Los proveedores externos ofrecen funciones más seguras y avanzadas para administrar Kubernetes Secrets. A continuación, presentamos algunos servicios populares de administración de Secrets de terceros.

AWS Secrets Manager

AWS Secrets Manager ofrece una forma segura y sencilla de almacenar y rotar Secrets. Proporciona una consola de administración unificada para todos nuestros recursos de Amazon Web Services (AWS). La herramienta AWS Secrets Manager está integrada con Kubernetes, lo que nos permite almacenar de forma segura nuestros Secrets cifrados en Kubernetes. Luego, podemos usar la API de Kubernetes para acceder a estos Secrets durante la ejecución, sin preocuparnos por exponerlos en nuestro código.

Este servicio de administración de Secrets permite recuperar, ver y administrar credenciales y Secrets de AWS en una única ubicación segura. Podemos usar AWS Secrets Manager con otros servicios de AWS, como AWS Identity and Access Management (IAM), AWS Key Management Service (AWS KMS) y AWS Simple Storage Service (S3).

Azure Key Vault y Azure Kubernetes Service

Microsoft Azure Key Vault es un administrador de Secrets que permite a los usuarios almacenar y usar claves criptográficas. Podemos respaldar y recuperar objetos de almacén eliminados, registrar y monitorear Secrets, y usar almacenes de claves para autenticar usuarios.

Además, podemos usar Azure Kubernetes Service (AKS) para la autorización de Azure RBAC y Kubernetes RBAC. También podemos usar Azure RBAC para controlar el acceso a los recursos mediante asignaciones de roles. Además, autoriza a grupos y usuarios, mientras que el RBAC integrado de Kubernetes permite usar cuentas de servicio de Kubernetes.

HashiCorp Vault

HashiCorp Vault es una herramienta de código abierto para administrar Secrets, almacenarlos y proteger datos confidenciales. Esta herramienta administra el acceso de los usuarios a los datos confidenciales y nos permite rotarlos o revocar el acceso cuando existe una amenaza de seguridad.

Podemos usar HashiCorp Vault para implementar distintas medidas de seguridad de Kubernetes, como el cifrado de datos, el acceso basado en identidad y la administración de Secrets. HashiCorp Vault usa cifrado TSL y AES de 256 bits para proteger los datos en tránsito y en reposo, respectivamente.

Conclusión

Los Secrets autentican a usuarios y servicios, y controlan el acceso a recursos y otros Secrets. Kubernetes Secrets permite almacenar datos en un objeto secreto, al que luego pueden acceder o que pueden modificar los clientes de Kubernetes. Como los Secrets contienen datos confidenciales, como tokens, claves y contraseñas, es fundamental seguir las mejores prácticas para protegerlos.

Hay varias formas de proteger nuestros Secrets. Para empezar, debemos habilitar el cifrado en reposo. Cifrar los Secrets en reposo mejora su seguridad. Sin embargo, cifrar los objetos Kubernetes Secret en reposo es solo una parte de cómo mantenerlos protegidos. También debemos controlar el acceso a los Secrets mediante reglas de RBAC. El marco de RBAC integrado de Kubernetes nos permite restringir el acceso de usuarios o programas, y dejar disponibles solo los recursos o la información necesarios. También podemos usar un servicio externo de administración de Secrets, como los mencionados anteriormente, para ayudar a protegerlos.

Para administrar correctamente los Secrets, tanto los desarrolladores como los administradores de clústeres de Kubernetes deben monitorear de cerca la seguridad de nuestra información confidencial. Además de las mejores prácticas que se describen aquí, consulta la guía de Kubnernetes para administrar Secrets, dirigida tanto a desarrolladores como a administradores de clústeres, para mantener tus Secrets protegidos.

Proteger las credenciales y otros secretos es solo un paso para ejecutar aplicaciones más seguras: debes proteger cada etapa del ciclo de vida del desarrollo de software. Identifica y mitiga posibles vulnerabilidades en el código que escribes y en los proyectos de código abierto que usas con Snyk Code y Snyk Open Source. Usa Snyk Container para comenzar con una imagen base más segura e identificar cualquier vulnerabilidad adicional que puedas introducir durante el proceso de compilación. Por último, verifica con Snyk IaC que el código que implementas no tenga brechas de seguridad.

Artículos relacionados:

• Administración de Secrets: herramientas y mejores prácticas

• Seguridad de AWS

• Cómo crear imágenes de Docker con Kubernetes

• 10 configuraciones de contexto de seguridad de Kubernetes que debes conocer

• Implicaciones de seguridad de los operadores de Kubernetes

• Monitoreo de Kubernetes

• Orquestación de contenedores