Autenticación y Autorización (Kubernetes). Bloque 1. Tema 1.1 del CKA.


Introducción:

La autenticación en Kubernetes es un aspecto crítico para la seguridad y control de acceso dentro de un clúster. Kubernetes proporciona varios mecanismos de autenticación para usuarios y cuentas de servicio, que deben pasar a través del API Server para realizar cualquier operación. En este artículo, revisaremos cómo funciona la autenticación y cómo puedes usar herramientas como kubectl y curl para interactuar de manera segura con el clúster.

En primer lugar, ¿Qué es la autenticación y la autorización?

•    Autenticación: Es el proceso de verificar quién es un usuario. Responde a la pregunta "¿Quién eres?".

•    Autorización: El proceso de determinar qué acciones puede realizar un usuario autenticado. Responde a la pregunta "¿Qué puedes hacer?".

¿Qué es la autenticación en Kubernetes?

La autenticación en Kubernetes es el proceso mediante el cual el sistema verifica la identidad de los usuarios y cuentas de servicio que intentan acceder al clúster. 

En Kubernetes existen dos tipos principales de identidades:

  • Usuarios: Personas que interactúan con el clúster (administradores, desarrolladores, etc.).
  • Cuentas de Servicio: Identidades que representan aplicaciones o servicios que se ejecutan dentro del clúster.

Métodos de Autenticación

Kubernetes soporta varios mecanismos de autenticación:

  1. Certificados X.509: Los certificados TLS emitidos por una CA (Autoridad de Certificación) se usan para autenticar usuarios y servicios. Los certificados incluyen información sobre la identidad de un usuario. (Haz click para más información)

  2. Tokens de cuentas de servicio: Cada Pod en Kubernetes se asocia con una cuenta de servicio (Service Accounts), que puede autenticarse usando un token. Estos tokens son manejados por Kubernetes automáticamente.

  3. Archivo de Configuración (kubeconfig): Los usuarios generalmente interactúan con Kubernetes a través de archivos kubeconfig, que contienen la configuración para conectarse a uno o más clústeres. Estos archivos incluyen credenciales y certificados.

  4. OAuth/OpenID Connect (OIDC): Kubernetes puede integrarse con proveedores de identidad externos para gestionar la autenticación, como Google, Azure o Keycloak, usando protocolos como OpenID Connect.

El API Server y la Autenticación

El API Server es el punto central de todas las interacciones en Kubernetes. Todos los componentes, tanto internos como externos, se comunican con el API Server a través de una API REST.

Cuando un cliente (como kubectl o curl) se conecta al API Server, este evalúa la solicitud y verifica si el cliente está autenticado. Si la autenticación es exitosa, pasa a verificar los permisos de autorización.

La autenticación a través del API Server puede configurarse mediante diversos mecanismos, incluyendo:

  • Certificados TLS: Kubernetes utiliza estos certificados para verificar la identidad de los usuarios.
  • Tokens: Para servicios internos, se utilizan tokens de cuenta de servicio.
  • Integraciones externas: OpenID Connect permite integrar un proveedor de identidad externo, facilitando la autenticación para usuarios humanos.

Autenticación con kubectl

El comando kubectl es la herramienta estándar para interactuar con Kubernetes. Para autenticarse, kubectl utiliza el archivo kubeconfig, que contiene la información necesaria para conectarse al clúster, incluyendo certificados y tokens.

Un ejemplo típico de uso del archivo kubeconfig sería:

kubectl --kubeconfig=/path/to/kubeconfig get pods

Este archivo tiene varios campos clave:

  • apiVersion: La versión de la API utilizada.
  • clusters: Detalles sobre los clústeres.
  • users: Información sobre las credenciales del usuario (certificados, tokens).
  • contexts: Define la combinación de clúster, usuario y namespace.

Autenticación con curl usando Certificados TLS

También puedes interactuar directamente con el API Server usando curl. Esto es útil cuando quieres hacer solicitudes HTTP manuales sin utilizar kubectl. Para esto, debes usar certificados TLS emitidos por la CA del clúster.

Por ejemplo, para obtener una lista de Pods, puedes ejecutar:

curl --cacert /path/to/ca.crt \
    --cert /path/to/client.crt \
    --key /path/to/client.key \
    https://<API_SERVER>/api/v1/pods
  • --cacert: El certificado de la autoridad de certificación (CA) del clúster.
  • --cert: El certificado del cliente.
  • --key: La clave privada del cliente.

Este enfoque es menos automático que kubectl, pero te ofrece un control granular sobre las solicitudes al API Server.

Mejores Prácticas en la Autenticación

Para mantener la seguridad de tu clúster, es importante seguir ciertas mejores prácticas relacionadas con la autenticación:

  • Principio de mínimo privilegio: Solo otorgar los permisos estrictamente necesarios.
  • Rotación de credenciales: Cambiar regularmente los tokens y certificados para evitar compromisos de seguridad.
  • Autenticación multifactor (MFA): Si es posible, integrar una segunda capa de autenticación para usuarios.
  • Uso de kubeconfig seguro: Proteger los archivos kubeconfig y sus certificados para evitar fugas de información.

Conclusión

La autenticación es un componente esencial para garantizar la seguridad en un clúster de Kubernetes. Comprender los mecanismos disponibles, como los certificados TLS, tokens y la integración con proveedores externos, es clave para mantener un clúster seguro y bien gestionado. Usando herramientas como kubectl y curl, puedes autenticarte y gestionar el acceso al API Server de manera efectiva.


Autorización en Kubernetes

Una vez que un usuario o cuenta de servicio ha sido autenticado en Kubernetes, el siguiente paso es determinar qué acciones puede realizar sobre los recursos del clúster. Este proceso se llama autorización, y Kubernetes utiliza varios mecanismos para decidir si la solicitud debe ser permitida o denegada. El más común y recomendado es el Role-Based Access Control (RBAC).

Role-Based Access Control (RBAC)

RBAC es un mecanismo flexible y granular que te permite definir quién puede hacer qué dentro del clúster. Utiliza varios componentes clave:

  1. Roles: Un conjunto de permisos que se aplican dentro de un namespace específico. Estos permisos definen qué acciones pueden realizarse sobre qué recursos dentro de ese namespace. Ejemplo de un Role:


    kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

    Este ejemplo define un Role que permite leer (get, list) Pods en el namespace default.

  2. ClusterRoles: Similar a un Role, pero se aplica a todo el clúster en lugar de un namespace específico. Esto es útil para asignar permisos a nivel global, como gestionar nodos o recursos de clúster. Ejemplo de un ClusterRole:


    kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list"]

    Este ClusterRole otorga permisos para leer información sobre los nodos del clúster.

  3. RoleBindings: Asocian un Role a un usuario, grupo o cuenta de servicio dentro de un namespace específico. Por ejemplo:

    yaml


    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

    Este RoleBinding asigna el Role pod-reader al usuario jane en el namespace default.

  4. ClusterRoleBindings: Similar a RoleBinding, pero aplica a ClusterRoles y puede otorgar permisos en todo el clúster. Ejemplo de un ClusterRoleBinding:

    yaml

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-nodes
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

    Este ClusterRoleBinding permite que todos los usuarios autenticados (grupo system:authenticated) lean información de los nodos del clúster.

Componentes Clave en RBAC

  • Subjects: Los sujetos a los que se les asignan Roles o ClusterRoles pueden ser:

    • Usuarios: Identidades humanas, generalmente autenticadas mediante certificados o integración con sistemas externos.
    • Cuentas de servicio: Identidades usadas por las aplicaciones que corren dentro del clúster.
    • Grupos: Un conjunto de usuarios que comparten permisos comunes.

  • Verbos: Las acciones que se pueden realizar sobre los recursos, como:

    • get: Obtener un recurso específico.
    • list: Listar múltiples recursos.
    • create: Crear un nuevo recurso.
    • update: Modificar un recurso existente.
    • delete: Eliminar un recurso.
    • patch: Aplicar cambios parciales a un recurso.

  • Recursos: Los objetos de Kubernetes sobre los que se pueden realizar acciones, como:

    • Pods
    • Deployments
    • Services
    • ConfigMaps
    • Nodes

El API Server y la Autorización

El API Server es quien toma las decisiones de autorización. Después de que un usuario o cuenta de servicio ha sido autenticado, el API Server consulta las políticas de autorización configuradas para verificar si el cliente tiene permiso para realizar la solicitud.

Kubernetes permite configurar múltiples mecanismos de autorización. El más común es RBAC, pero también existen otros como Node Authorization y Webhook Authorization.

Flujo de Trabajo: Autenticación y Autorización

  1. Un usuario o servicio envía una solicitud al API Server.
  2. El API Server verifica la identidad del solicitante mediante los mecanismos de autenticación.
  3. Si la autenticación es exitosa, el API Server consulta las políticas de autorización para determinar si el usuario tiene permisos sobre el recurso solicitado.
  4. Si la autorización es exitosa, la solicitud se ejecuta; si falla, el API Server devuelve un error de permiso denegado (403 Forbidden).

Conclusión

La autorización en Kubernetes, gestionada a través de RBAC, es crucial para controlar qué usuarios o aplicaciones pueden hacer en tu clúster. Definir correctamente Roles, ClusterRoles, RoleBindings y ClusterRoleBindings es esencial para implementar un modelo de seguridad sólido y granular. Tener un buen conocimiento de estos mecanismos es vital para el examen CKA, ya que te permite mantener seguro y bajo control tu entorno de Kubernetes.


Comentarios

Publicar un comentario