El modelo de Control de Acceso Basado en Atributos (ABAC) permite granularidad en la seguridad definiendo reglas que evalúan atributos del sujeto, recurso y contexto para autorizar operaciones. Para habilitar este módulo en el cluster, es obligatorio especificar el archivo de política durante el arranque del componente API Server mediante los argumentos:

• --authorization-mode=ABAC
• --authorization-policy-file=/ruta/al/archivo/de/politica

Cualquier cambio en el archivo de configuración requiere reiniciar el servicio de controlador para aplicar las nuevas directivas.

Estructura del Archivo de Política

La sintaxis utilizada es una lista de objetos JSON, donde cada línea representa una regla independiente. Cada entrada debe contener campos obligatorios para definir su validez semántica dentro del motor de autorización:

• Metadatos del Documento: Se define apiVersion con el valor abac.authorization.kubernetes.io/v1beta1 y kind como Policy.
• Esquema de Especificación (spec): Contiene los criterios de coincidencia agrupados en las siguientes categorías:

Sujetos (Subject Matching)

Los usuarios o grupos pueden ser identificados explícitamente o mediante marcadores reservados:

• user: Nombre de usuario coincidente con el proporcionado en el fichero de autenticación.
• group: Grupo al cual pertenece el solicitante.
• system:authenticated: Cualquier usuario con credenciales válidas.
• system:unauthenticated: Solicitudes anónimas sin autenticación.

Recursos (Resource Matching)

Se determinan los recursos a los que se aplica la regla utilizando combinaciones de estos atributos:

• apiGroup: Familia de la API (ej. extensions). El asterisco * abarca todas.
• namespace: Espacio de nombres específico (ej. default) o * para todos.
• resource: Tipo de objeto (ej. pods, deployments). También admite comodines globales.

Operaciones no Recursos (nonResourceMatching)

Para rutas HTTP que no son recursos del API estándar:

• nonResourcePath: Ruta exacta o patrón (ej. /healthz, /apis/*).

Restricción de Lectura (Readon Mode)

El atributo readonly actúa como filtro verbético:

• true: Limita los permisos a operaciones de lectura (GET, LIST, WATCH) para recursos, o solo GET para rutas no recursivas.
• false u omitido: Permite operaciones completas (CRUD) según lo definido por otros filtros.

Nota técnica: Los campos nulos se comportan como sus valores predeterminados (false, 0, o vacío), lo cual implica que omitir restricciones suele otorgar acceso amplio si otras condiciones coinciden.

Consideraciones sobre Herramientas de Cliente

Herramientas administrativas como kubectl interactúan con los endpoints /api y /apis para introspeccionar tipos disponibles. Si se activa ABAC estricto, estas rutas deben permitirse explícitamente en las reglas de nonResourcePath. Para diagnosticar errores de permiso ocultos, se recomienda ejecutar comandos con alta verbosidad:

kubectl --v=8 get nodes

Escenarios de Políticas Comunes

A continuación se muestran ejemplos de configuraciones JSON reestructuradas para diferentes roles operativos:

<code>{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "cluster_admin_root",
    "namespace": "*",
    "resource": "*",
    "apiGroup": "*"
  }
}</code>
<p><em>Interpretación: Usuario maestro con capacidad total sobre cualquier objeto en el clúster.</em></p>

<code>{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "agente_de_nodos",
    "namespace": "*",
    "resource": "pods",
    "readonly": true
  }
}</code>
<p><em>Interpretación: Agente de nodo restringido solo a consultas de estado de pods.</em></p>

<code>{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "agente_de_nodos",
    "namespace": "*",
    "resource": "events"
  }
}</code>
<p><em>Interpretación: Capacidad completa sobre logs y eventos del sistema.</em></p>

<code>{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "desarrollador_betas",
    "namespace": "ambiente-beta",
    "resource": "deployments",
    "readonly": true
  }
}</code>
<p><em>Interpretación: Un desarrollador específico puede inspeccionar despliegues únicamente en el espacio de nombres designado.</em></p>

<code>[
  {
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
      "group": "system:authenticated",
      "readonly": true,
      "nonResourcePath": "*"
    }
  },
  {
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
      "group": "system:unauthenticated",
      "readonly": true,
      "nonResourcePath": "/"
    }
  }
]</code>
<p><em>Interpretación: Regla para permitir acceso global de lectura vía HTTP para todo tipo de solicitud, incluyendo autenticadas y públicas.</em></p>

<h2>Gestión de Cuentas de Servicio</h2>
<p>Kubernetes genera identificadores automáticos para las cuentas de servicio bajo el formato:</p>
<code>system:serviceaccount:<NOMBRE_NSPACE>:<NOMBRE_SERVICIO</code>
<p>Al crear un espacio de nombres nuevo, se provisiona una cuenta por defecto siguiendo la misma convención (<code>system:serviceaccount:<ns>:default</code>). Por ejemplo, para permitir control total a la cuenta predeterminada dentro del namespace crítico:</p>
<code>{
  "apiVersion":"abac.authorization.kubernetes.io/v1beta1",
  "kind":"Policy",
  "spec":{
    "user":"system:serviceaccount:kube-system:default",
    "namespace":"*",
    "resource":"*",
    "apiGroup":"*"
  }
}</code>
<p>Es imperativo notar que esta funcionalidad ha sido descontinuada formalmente desde la versión 1.6 de Kubernetes, recomendándose migrar hacia modelos RBAC o OPA/Gatekeeper.</p>