La seguridad a nivel de red y de sistema no era la prioridad en los inicios de Kubernetes en sus primeras versiones. Esto ya lo comentamos anteriormente, así como su evolución y mejora más que relevante en versiones modernas, pero no todo acaba aquí.

Evitar que los “malos” puedan hacer daño cuando están dentro del sistema es necesario, pero lo es en mayor medida evitar que entren por todos los medios.

De igual forma, los mecanismos de control de acceso, autenticación (AuthN) y autorización (AuthZ) de Kubernetes, han ido mejorando y siendo cada vez más potentes y complejos. Tanto es así, que se ha convertido en una de las configuraciones más complejas en la instalación y mantenimiento del cluster, sobre todo para los más novicios.

En AWS se han puesto manos a la obra para fusionar sus sistemas de autenticación y autorización de su servicio AWS IAM integrado dentro de Kubernetes mediante API. Esto permite que los administradores de sistema podamos definir el control de acceso al cluster desde su instalación inicial e integrado en sistemas de infraestructura como código, como Terraform.

Para ello, AWS ha evolucionado su mecanismo de acceso al servicio de AWS EKS anterior (configmap aws-auth) por el mecanismo de access entries.

Podemos elegir entre tres tipos de autenticación:

• CONFIG_MAP: método tradicional, que en futuras versiones quedará obsoleto.
• API_AND_CONFIG_MAP: nuevo método basado en access entries pero compatible con configuraciones anteriores por configmap. Este método nos facilita la migración en clusters en funcionamiento.
• API: autenticación mediante access entries. Ten en cuenta que una vez habilitado no es posible dar marcha atrás a los métodos anteriores.

Para establecer el tipo de autenticación, en el ejemplo API_AND_CONFIG_MAP, mediante API de AWS podemos hacerlo de esta forma:

aws eks update-cluster-config \
   --name <CLUSTER_NAME> \
   --access-config authenticationMode=API_AND_CONFIG_MAP

Si ya contamos con un cluster de EKS configurado con aws-auth, tendremos que realizar una migración de estas configuraciones al nuevo mecanismo de access entries.

De todas formas, al activar el método de autenticación por API en un cluster configurado por configMag aws-auth, el servicio importa dichas configuraciones como access entries, para garantizar el correcto funcionamiento.

Estas entradas son básicamente de dos tipos (si no usamos otros servicios como AWS Fargate):

• Tipo “EC2_LINUX”: es el tipo por defecto cuando se utiliza un role de tipo servicio ec2 para el acceso al cluster. Permite a los nodos unirse al cluster con el role de system:node.

$ aws eks create-access-entry \
--principal-arn <IAM_PRINCIPAL_ARN> \
--cluster-name <CLUSTER-NAME> \
– type “EC2_LINUX”

{
  "accessEntry": {
      "clusterName": "<CLUSTER-NAME>",
      "principalArn": "<IAM_PRINCIPAL_ARN>",
      "kubernetesGroups": [
          "system:nodes"
      ],
      "accessEntryArn": "<ACCESS-ENTRY-ARN>",
      "tags": {},
      "username": "system:node:{{EC2PrivateDNSName}}",
      "type": "EC2_LINUX"
  }
}

• Tipo “STANDARD”: es el tipo por defecto de un role delegado de identificación de usuarios. Estos usuarios deben asociarse a una política de acceso, ya sea predefinida por AWS o de un RBAC definido en el cluster. Las políticas de acceso predefinidas por AWS son las siguientes:

{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSClusterAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
},
{
"name": "AmazonEKSEditPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
},
{
"name": "AmazonEKSViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
}

Pongamos un ejemplo: crear un acceso de solo lectura para un IAM role de usuario que pueda acceder a todo el cluster.

Primero creamos el objeto access entry asociando el ARN al cluster de EKS.

$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>
  
{
    "accessEntry": {
        "clusterName": "<value>",
        "principalArn": "<value>",
        "kubernetesGroups": [],
        "accessEntryArn": "<ACCESS_ENTRY_ARN>",
        "tags": {},
        "username": "arn:aws:sts::<AWS_ACCOUNT_ID>:assumed-role/<ROLE_NAME>/{{SessionName}}"
    }
}

Una vez creado le asociamos la política predefinida en AWS de solo lectura, a todo el cluster:

$ aws eks associate-access-policy --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
  --access-scope type=cluster
  
  {
    "clusterName": "<CLUSTER_NAME>",
    "principalArn": "<AWS_IAM_PRINCIPAL_ARN>",
    "associatedAccessPolicy": {
        "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
        "accessScope": {
            "type": "cluster",
            "namespaces": []
        },
    }
}

Si queremos definir el acceso a recursos específicos, podemos asociar un IAM role a una política de acceso basada en RBAC de tipo Cluster o por Namespace.

Un ejemplo con permisos de administrador del cluster con RBAC nativo:

# cluster role binding
$ kubectl get cluster-admin-ae
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-ae
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: eks-admins

# Create cluster access entry
$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN> \
  --kubernetes-groups eks-admins

A continuación te exponemos las ventajas e inconvenientes del proceso.

Ventajas

• Definición de la seguridad de acceso en infraestructura como código: unificar la instalación con los permisos de acceso al cluster nos da mayor agilidad en la automatización de procesos, sobre todo en entornos de desarrollo que pueda interesar crearlos o destruirlos solo cuando interesa utilizarlos. 
• Evita errores humanos al tener toda la información unificada en un mismo entorno de configuración. 
• Permite de un solo proceso garantizar los accesos definidos, permitiendo una mejor auditoría y mantenimiento de la seguridad del sistema, sobre todo si deshabilitamos la autenticación por configmap.

Inconvenientes

• El principal inconveniente es no formar parte de la configuración nativa de Kubernetes, (como pueda ser una autenticación por token y RBAC de autorización), de forma que si cambiamos de proveedor tendremos que adaptar la configuración de acceso al nuevo entorno (AKS, GKE, bare metal…etc). En cualquier caso, podemos evitar en gran medida este acoplamiento definiendo los permisos de los usuarios en RBAC y asociándolo a IAM roles delegados. Estas dependencias son difíciles de evitar por completo. Si cambiamos de proveedor y queremos aprovechar las ventajas que nos aporte este nuevo, en éste y en otros servicios que vayan relacionados con Kubernetes, tendremos que abordar adaptaciones.

Si has llegado a este punto, ya debes estar listo para abordar la migración a access entries en tus clusters de EKS. También tienes la opción de preguntarnos y te ayudamos :-)