Control de acceso de la API de Kubernetes

Traducido de documentos oficiales

El usuario usa kubectl o REST para solicitar acceso a la API y la biblioteca cliente. Tanto los usuarios humanos como las cuentas de servicio pueden autorizar el acceso a la API. Cuando la solicitud llega a la API, pasa por varios pasos.

Seguridad de transmisión

En un clúster de Kubernetes típico, el servidor API se encuentra en el puerto 6443. API Server presenta el certificado. Este certificado suele ser autofirmado, por lo que $USER/.kube/configel certificado raíz en la máquina del usuario generalmente contiene el certificado del servidor API. Este certificado raíz se usa para reemplazar el certificado raíz predeterminado del sistema cuando se especifica. Este certificado generalmente se escribe automáticamente cuando crea el clúster $USER/.kube/config. Si el clúster tiene varios usuarios, el creador debe compartir el certificado con ellos.

Certificación

Cuando se establece la conexión TLS, la solicitud HTTP ingresa al paso de autenticación. Como se muestra en el paso 1 de la figura anterior . El script de creación del clúster o el administrador del clúster configura el servidor API para ejecutar uno o más módulos de autenticación. Estos módulos se detallan aquí .

La entrada para el paso de autenticación es la solicitud HTTP completa, sin embargo, generalmente solo se verifica el encabezado y / o el certificado del cliente.

El módulo de autenticación incluye certificado de cliente, contraseña, token de texto plano, token de autoservicio y token JWT (utilizado por la cuenta de servicio).

Puede especificar varios módulos de autenticación. En este momento, cada módulo intenta la autenticación en orden hasta que uno de ellos pasa la autenticación.

Si la solicitud no se puede autenticar, se rechaza con el código de estado HTTP 401. De lo contrario, el usuario se autentica como especificado usernamey el nombre de usuario se puede utilizar para la toma de decisiones en los pasos posteriores. Algunos autenticadores también proporcionan autenticación de grupos de usuarios.

Aunque Kubernetes se utiliza usernamepara tomar decisiones de control de acceso y registrar solicitudes, no tiene objetos de usuario ni almacena nombres de usuario u otra información relacionada con el usuario en su almacén de objetos.

Autorización

Una vez autenticada la solicitud, debe autorizarse. Como se muestra en el paso 2 de la figura anterior .

La solicitud debe incluir el nombre de usuario del solicitante, la acción solicitada y el objeto afectado por la acción. Si existe una política que indique que el usuario tiene derecho a completar la acción solicitada, la solicitud está autorizada.

Por ejemplo, si Bob tiene la siguiente estrategia, solo puede leer projectCariboula información del pod del espacio de nombres:

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

Si Bob realiza la siguiente solicitud, esta solicitud está autorizada para permitir:

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

Si Bob solicita escribir en un objeto en este espacio de nombres, se deniega su autorización. Si solicita leer recursos en otros espacios de nombres, también se rechaza.

Kubernetes requiere el uso de atributos REST para interactuar con organizaciones existentes (la O en el certificado raíz) o el sistema de control de acceso del proveedor de la nube. Es importante utilizar el formato REST porque estos sistemas de control pueden interactuar con API distintas de la API de Kubernetes.

Kubernetes admite varios módulos de autorización, como el modo ABAC, el modo RBAC y el modo Webhook. El administrador configura el módulo de autorización utilizado por API Server al crear un clúster. Si se configura más de uno, Kubernetes verificará cada uno, y si algún módulo autoriza la solicitud, la solicitud puede continuar. Si todos los módulos rechazan la solicitud, la solicitud de pregunta está prohibida. (Código de estado HTTP 403)

Para obtener más información sobre la autorización de Kubernetes, consulte Descripción general de la autorización

Control de acceso

El módulo de control de admisión es un módulo de software que puede modificar o rechazar solicitudes. Además de los atributos disponibles para el módulo de autorización, el módulo de control de admisión puede acceder a los objetos que se están creando o actualizando. Actúan sobre objetos que se crean, eliminan, actualizan o conectan (proxy), pero no se leen.

Puede configurar varios controladores de admisión y llamarlos uno por uno en secuencia.

Como se muestra en el paso 3 de la figura.

A diferencia de los módulos de autenticación y autorización, si es rechazada por cualquier módulo de control de admisión, la solicitud es rechazada inmediatamente.

Además de rechazar objetos, el controlador de admisión también puede establecer valores predeterminados complejos para los campos.

Los módulos de control de admisión disponibles se describen aquí .

Una vez que la solicitud pasa por todos los controladores de admisión, se verificará utilizando la rutina de verificación del objeto API correspondiente y luego se escribirá en el almacenamiento de objetos ( paso 4 en la figura ).

IP y puerto del servidor API

El servidor API realmente puede servir a dos puertos:

1. Puerto local:
   • Se utiliza para pruebas y arranque, y otros componentes del nodo maestro se comunican con el servidor API
   • No TLS
   • El puerto predeterminado es 8080, --insecure-portmodificación de parámetros
   • La IP predeterminada es localhost, --insecure-bind-addressmodificación de parámetros
   • Solicitud para omitir el módulo de autenticación y autorización
   • La solicitud es procesada por el módulo de control de admisión.
   • Protegido por la necesidad de acceder al host
2. Puerto seguro
   • Use tanto como sea posible
   • Utilice TLS. Parámetro --Tls-cert-file y --tls-private-key-file para configurar el certificado
   • Puerto predeterminado 6443, modificación del parámetro del puerto seguro
   • La IP predeterminada es la IP de la primera tarjeta de red no localhost, modificar -bind-address
   • La solicitud es procesada por el módulo de autenticación y autorización.
   • La solicitud es procesada por el módulo de control de admisión.
   • Operación del módulo de autenticación y autorización