Los Secrets de Kubernetes ofrecen una manera de almacenar y gestionar información confidencial. Sin embargo, es importante comprender sus limitaciones y cómo protegerlos adecuadamente.
Vamos a explorar un poco sus caracteristicas y analizar como funcionan en base al a documentación Oficial tanto de nuestros Cloud Providers como de Kubernetes.
¿Qué son los Objetos Secrets?
Un Secret en Kubernetes es un objeto que contiene datos sensibles en pequeña cantidad, como contraseñas, tokens o SSH keys. La utilización de este recurso, permite pasar información sensible a los Pods o contenedores si tenenr que exponerlos en el codigo de la aplicación y estos valores pueden ser expuestos como Volume Mounts o Variables de Entorno.
Tipos de Secrets
El tipo de Secret utilizado por defecto es el Opaque. Este se utiliza cuando no se especifica ningun tipo. Si utilizamos el comando “kubectl create”, debemos utilizar el subcomando “generic” para indicar este tipo.
kubectl create secret generic empty-secretPero tambien existen otros tipos de Secrets:
| Built-in Type | Usage |
|---|---|
Opaque | arbitrary user-defined data |
kubernetes.io/service-account-token | ServiceAccount token |
kubernetes.io/dockercfg | serialized ~/.dockercfg file |
kubernetes.io/dockerconfigjson | serialized ~/.docker/config.json file |
kubernetes.io/basic-auth | credentials for basic authentication |
kubernetes.io/ssh-auth | credentials for SSH authentication |
kubernetes.io/tls | data for a TLS client or server |
bootstrap.kubernetes.io/token | bootstrap token data |
Secrets vs. ConfigMaps
A diferencia de los ConfigsMaps, que están diseñados para almacenar datos no-confidenciales, los Secrets están diseñados para almacenar información confidencial.
Entonces, ¿son seguros?
Los Values de los Secrets se guardan en el etcd (base de datos key-value del cluster) están codificados por defecto, pero no están encriptados por defecto.
¿Esto que quiere decir? Qué un secreto puede ser decodificado utilizando un simple comando base64 en linux y exponer información sensible para quienes tengan acceso. Cualquier persona (o atacante) que tenga acceso a la API y los RBAC necesarios puede ver el valor del secret.
Debemos entender que Base64 NO es un metodo de encripción y solo provee una capa adicional de confidencialidad sobre el texto plano.
Buenas Practicas para el manejo de Secrets en Kubernetes
Existen varias recomendaciones para el manejo de nuestros secretos en K8s que son complementados con la seguridad general de nuestro cluster. Vamos a revisar algunas de las practicas recomendadas:
Encryption at rest
Cómo comentamos anteriormente, por defecto, etcd no está encriptada. Pero podemos configurar la encriptacion de nuestros secretos almacenados. Para esto podemos revisar la siguiente nota: Encrypting Confidential Data at Rest | Kubernetes
Configurar acceso Least-Privilege a los secretos
Es recomendado planificar el mecanismo de control de acceso de nuestro cluster utilizando Kubernetes RBAC.
Es recomendable seguir las buenas prácticas generales de RBAC:
- Componentes: Restringir el acceso de “watch” o “list” solo a los componentes más privilegiados a nivel del sistema. Solo otorga acceso “get” solo si lo requiere.
- Usuarios: Restringe el acceso de “get”, “watch” o “list” a los Secrets. Solo los administradores del clúster deben tener acceso a etcd, incluyendo el acceso de solo lectura.
Utilizar herramientas de terceros
Kubernetes en su documentación oficial, recomienda la utilización de herramientas de terceros para manejar los Secrets.
En nuestro caso, podemos verificar la integración con los Secret Managers de nuestro Cloud Provider favorito.
Evitar compartir secretos en SCM
Por ningun motivo ni circunstancia debemos hardcodear un valor de un Secret en nuestro SCM, ya sea utilizando un Manifest para nuestro secret o en el codigo de nuestra aplicación. Debemos asegurarnos que estos valores sean referenciados de fuentes externas a través de nuestros pipelines con archivos seguros o variables de entorno.
¿Cómo manejan esto los Cloud Providers?
En este caso vamos a estar revisando cuales son los features y consideraciones que AKS y GKE nos brindan para el manejo de los Secret y cuales son las integraciones con sevicios propios de Secrets.
Encryption at rest
Ambas plataformas tiene habilitado Encryption at Rest para los Secrets en etcd:
- Azure: https://learn.microsoft.com/en-us/azure/aks/concepts-security#kubernetes-secrets
- GKE: https://cloud.google.com/kubernetes-engine/docs/how-to/encrypting-secrets#:~:text=By%20default%2C%20Google%20Kubernetes%20Engine,additional%20action%20on%20your%20part.
Tanto GKE como AKS encriptan los datos at-rest por defecto y permiten el uso de llaves manejadas por los clientes utilizando KMS.
Adicionalmente GKE permite utilizar CMEK para la encriptación a nivel de aplicación
Integración de Cloud Secrets Managers
Adicionalmente, utilizando Managed-Kubernetes en Azure o GKE podemos utilizar las funcionalidades de integración nativas con los Secret Managers como KeyVault o GCP Secret manager.
GKE: Integración de Secret Manager
En GKE, podemos integrar Secret Manager utilizando el Add-on de Secret Manager:
AKS: Integración con Azure KeyVault
En Azure, podemos integrar Key Vault con AKS:
Ambas integraciones utilizan el Secrets Store CSI Driver: Concepts – Secrets Store CSI Driver (k8s.io)
Leave a Reply