En esta página se describen las funciones de seguridad incluidas en GKE en AWS, incluida cada capa de su infraestructura, y cómo puede configurar las funciones de seguridad para que se adapten a sus necesidades.
Información general
GKE en AWS ofrece varias funciones para proteger tus cargas de trabajo, incluido el contenido de tu imagen de contenedor, el tiempo de ejecución del contenedor, la red del clúster y el acceso al servidor de la API del clúster.
Lo más recomendable es adoptar un enfoque por capas para proteger tus clústeres y cargas de trabajo. Puedes aplicar el principio de mínimos accesos al nivel de acceso que proporcionas a tus usuarios y cargas de trabajo. Es posible que tengas que hacer concesiones para permitir el nivel adecuado de flexibilidad y seguridad.
Responsabilidades compartidas
Cuando usas GKE en AWS, aceptas asumir ciertas responsabilidades en relación con tus clústeres. Para obtener más información, consulta Responsabilidades compartidas de los clústeres de GKE.
Autenticación y autorización
Para autenticarte en un clúster de usuario de GKE on AWS, puedes usar uno de los siguientes métodos:
- Con la herramienta
anthos-gke
. - Usar un token de cuenta de servicio de Kubernetes con la Google Cloud consola.
- Usar OpenID Connect (OIDC).
Para configurar un acceso más granular a los recursos de Kubernetes a nivel de clúster o en espacios de nombres de Kubernetes, puedes usar el control de acceso basado en roles (RBAC) de Kubernetes. El control de acceso basado en roles te permite crear políticas detalladas para definir a qué operaciones y recursos pueden acceder los usuarios y las cuentas de servicio. Con RBAC, puedes controlar el acceso de cualquier identidad validada.
Para simplificar y optimizar aún más tu estrategia de autenticación y autorización para Kubernetes Engine, GKE en AWS inhabilita el control de acceso basado en atributos (ABAC) antiguo.
Cifrado
De forma predeterminada, GKE en AWS cifra los datos en etcd
reposo, los volúmenes de EBS, los secretos de Kubernetes y los componentes del plano de control con AWS Key Management Service (KMS).
Para cifrar datos sensibles en tus clústeres de usuario, puedes usar una de las siguientes opciones:
- Secretos de Kubernetes
- HashiCorp Vault
Secretos de Kubernetes
Los secretos de Kubernetes almacenan datos sensibles, como contraseñas, tokens de OAuth y claves SSH, en tus clústeres. Almacenar datos sensibles en secretos es más seguro que hacerlo en ConfigMaps o en especificaciones de pods. Al usar secretos, puedes controlar cómo se usan los datos sensibles y reducir el riesgo de exponer los datos a usuarios no autorizados.
HashiCorp Vault
GKE on AWS puede usar HashiCorp Vault para proteger los secretos de tus clústeres de usuario. Para obtener más información, consulta Usar HashiCorp Vault en GKE on AWS.
Seguridad del plano de control
Los componentes del plano de control incluyen el servicio de gestión y el servidor de la API de Kubernetes, el programador, los controladores y la base de datos etcd del clúster de usuario. En GKE on AWS, los administradores locales gestionan los componentes del plano de control.
En GKE en AWS, los componentes del plano de control se ejecutan en AWS. Puedes proteger el servidor de la API de GKE en AWS mediante grupos de seguridad de AWS y ACLs de red.
Todas las comunicaciones en GKE en AWS se realizan a través de canales de Seguridad en la capa de transporte (TLS) regidos por las siguientes autoridades de certificación (CAs):
- La CA de etcd protege la comunicación del servidor de la API a las réplicas de etcd, así como el tráfico entre las réplicas de etcd. Esta CA tiene una firma automática.
- La AC del clúster de usuario protege la comunicación entre el servidor de la API y todos los clientes internos de la API de Kubernetes (kubelets, controladores y programadores). Esta CA está cifrada con KMS.
- La AC del servicio de gestión está cifrada con AWS KMS. Se crea cuando ejecutas
anthos-gke init
y se almacena en tu espacio de trabajo de Terraform. Cuando usasterraform apply
para crear el servicio de gestión, la clave de la AC se transfiere como datos de usuario de AWS EC2 y AWS KMS la descifra cuando se inicia el clúster.
En el caso del servicio de gestión, las claves del plano de control se almacenan en [nodos]{:.external} del plano de control. En el caso de los clústeres de usuarios, las claves se almacenan como secretos de Kubernetes en el plano de control del servicio de gestión.
La autenticación de clústeres en GKE on AWS se gestiona mediante certificados y tokens de portador de cuentas de servicio. Como administrador, te autenticas en el plano de control mediante el certificado administrativo para acceder al servicio de gestión (que usas para crear la vinculación de roles inicial o para emergencias).
La rotación de certificados se gestiona de las siguientes formas:
- En el caso del servidor de la API, los planos de control y los nodos, GKE en AWS rota los certificados TLS en cada actualización.
- También puedes rotar las credenciales de seguridad manualmente.
Seguridad de los nodos
GKE on AWS implementa tus cargas de trabajo en grupos de nodos de instancias de AWS EC2. En las siguientes secciones se explica cómo usar las funciones de seguridad a nivel de nodo en GKE en AWS.
Ubuntu
GKE en AWS usa una versión optimizada de Ubuntu como sistema operativo en el que se ejecutan el plano de control y los nodos de Kubernetes. Ubuntu incluye un amplio conjunto de funciones de seguridad modernas, y GKE en AWS implementa varias funciones que mejoran la seguridad de los clústeres, entre las que se incluyen las siguientes:
- Conjunto de paquetes optimizado.
- Google Cloud-adaptado kernel de Linux.
- Cuentas de usuario limitadas e inicio de sesión de root inhabilitado.
También hay disponibles otras guías de seguridad para Ubuntu, como las siguientes:
Actualizaciones de nodo
Debes actualizar tus nodos periódicamente. De vez en cuando, es posible que tengas que actualizar tus nodos con más urgencia debido a problemas de seguridad en el entorno de ejecución de contenedores, en Kubernetes o en el sistema operativo del nodo. Cuando actualizas un clúster de usuarios, el software de cada nodo se actualiza a la versión más reciente. Además, al actualizar los nodos, se cambian las credenciales de cifrado.
Proteger tus cargas de trabajo
Kubernetes permite a los usuarios aprovisionar, escalar y actualizar rápidamente cargas de trabajo basadas en contenedores. En esta sección se describen las tácticas que puedes usar para limitar los efectos secundarios de ejecutar contenedores en un clúster y los servicios de Google Cloud .
Limitar los privilegios de los procesos de los contenedores de pods
Limitar los privilegios de los procesos en contenedores es importante para la seguridad de tu clúster. Puedes definir opciones relacionadas con la seguridad con el contexto de seguridad de los pods y los contenedores. Estos ajustes te permiten cambiar la configuración de seguridad de tus procesos, como:
- Usuario y grupo que ejecutan el proceso.
- Funciones de Linux disponibles.
- Apropiación de privilegios.
El sistema operativo de los nodos predeterminado de GKE en AWS, Ubuntu, aplica las políticas de seguridad de Docker AppArmor predeterminadas a todos los contenedores iniciados por Kubernetes. Puedes ver la plantilla del perfil en GitHub. Entre otras cosas, el perfil deniega las siguientes funciones a los contenedores:
- Escribir en archivos directamente en un directorio de ID de proceso (
/proc/
). - Escribir en archivos que no estén en
/proc/
. - Escribir en archivos de
/proc/sys
que no sean/proc/sys/kernel/shm*
. - Montar sistemas de archivos.
Siguientes pasos
- Instala un servicio de gestión.
- Usa HashiCorp Vault en GKE on AWS.
- Rota tus credenciales de seguridad.