Gestionar la política de seguridad de pods en Kubernetes “Like a Boss” (Parte 2 de 3)

Vamos a continuar con la segunda parte de nuestro artículo de Cómo gestionar la política de de seguridad de pods en Kubernetes "Like a Boss" justo donde nos quedamos ayer. Cuando se crea una política de seguridad, por sí sola no hace nada, el usuario o la cuenta de servicio del pod necesita tener acceso para poder usar el verbo "use" de dicha política.

Figura 4: Gestionar la política de seguridad de pods en Kubernetes
“Like a Boss” (Parte 2 de 3)

La forma estándar en Kubernetes de dar acceso a recursos es a través de RBAC, del cual no entraremos en detalles ya que anteriormente hemos publicado un artículo de dos partes:

• Kubernetes: Cómo gestionar autorización de recursos con RBAC (Parte 1)
• Kubernetes: Cómo gestionar autorización de recursos con RBAC (Parte 2)

Para poder hacer uso de la política de seguridad, nuestro clúster debe tener habilitado un controlador de admisión para dichas políticas, concretamente para PodSecurityPolicy. Un controlador de admisión en Kubernetes es un componente que intercepta las llamadas al servidor de API del mismo justo antes de persistir dicha llamada, pero esto ocurre una vez la llamada ha sido autenticada y autorizada.

Unos ejemplos con minikube

Para ver algunos ejemplos haremos uso de minikube. Lo primero es arrancar minikube con el controlador de admisión de PodSecurityPolicy. Esta parte tiene un poco de truco, ya que cuando activamos dicho controlador, si no existe un objeto PodSecurityPolicy en el clúster, minikube rechaza la creación de pods, incluido los del sistema, por lo que minikube después de un buen rato de espera termina por parar la espera y nos da un error.

Aunque hay formas de solucionar este problema modificando la configuración de minikube (añadiendo un fichero dentro de ´~/.minikube/files/etc/kubernetes/addons´ PodSecurityPolicy), una forma muy sencilla es arrancando el clúster sin pasar ningún parámetro adicional:

Figura 5: Salida del comando de minikube start

Luego creamos un objeto PodSecurityPolicy con privilegios altos, ya que asignaremos esta política al group de sistema que levanta el clúster:

    apiVersion: extensions/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: privileged
      annotations:
        seccomp.security.alpha.kubernetes.io/allowedProfileNames: "*"
      labels:
        addonmanager.kubernetes.io/mode: EnsureExists
    spec:
      privileged: true
      allowPrivilegeEscalation: true
      allowedCapabilities:
      - "*"
      volumes:
      - "*"
      hostNetwork: true
      hostPorts:
      - min: 0
        max: 65535
      hostIPC: true
      hostPID: true
      runAsUser:
        rule: 'RunAsAny'
      seLinux:
        rule: 'RunAsAny'
      supplementalGroups:
        rule: 'RunAsAny'
      fsGroup:
        rule: 'RunAsAny'

Crea un fichero con ese contenido llamado psp-privileged.yaml (el nombre es indiferente y puedes elegir el que quieras) y ejecuta el siguiente comando para crear dicho objeto en el clúster:

    kubectl apply -f psp-privileged.yaml

Luego vamos a crear un Role a nivel de clúster. Recuerda que las políticas de seguridad deben ser asignadas a través de algún método de autorización, en nuestro caso RBAC:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: psp:privileged
      labels:
        addonmanager.kubernetes.io/mode: EnsureExists
    rules:
    - apiGroups: ['extensions']
      resources: ['podsecuritypolicies']
      verbs:     ['use']
      resourceNames:
      - privileged

Volcamos dicho contenido a un fichero llamado cr-privileged.yaml y ejecutamos el siguiente comando:

    kubectl apply -f cr-privileged.yaml

Y por último vamos a asignar dicho Role al grupo system:serviceaccounts:kube-system que es quién levanta el clúster:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: default:privileged
      namespace: kube-system
      labels:
        addonmanager.kubernetes.io/mode: EnsureExists
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: psp:privileged
    subjects:
    - kind: Group
      name: system:masters
      apiGroup: rbac.authorization.k8s.io
    - kind: Group
      name: system:nodes
      apiGroup: rbac.authorization.k8s.io
    - kind: Group
      name: system:serviceaccounts:kube-system
      apiGroup: rbac.authorization.k8s.io

De nuevo, volcamos ese contenido a otro fichero llamado rb-system.yaml y creamos dicho objeto:

    kubectl apply -f rb-system.yaml

Resumiendo, lo que acabamos de hacer es crear una política de seguridad de pods bastante permisiva, un role a nivel de clúster asociado a dicha política y por último le hemos dado permiso para usar dicha política al grupo de sistema kube-system.

Si no hacemos esto, el clúster no puede crear los pods de sistema necesarios. Ahora ya podemos habilitar en el clúster el controlador de admisión:

minikube start --extra-config=apiserver.
enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,
DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,
ValidatingAdmissionWebhook,ResourceQuota,PodSecurityPolicy
--extra-config=apiserver.authorization-mode=RBAC

En la siguiente imagen se puede ver  cuál es la salida de la ejecución de minikube, esta vez habilitando los plugins que se pueden ver en el comando.

Figura 6: Salida de la ejecución del comando con plugins activados

Y para que podáis ver el proceso completo de lo que hemos descrito en estas dos primeras partes del artículo, os hemos hecho este pequeño vídeo que resume el proceso completo de todo, en algo más de dos minutos y medio.


Figura 7: Demo de configuración de seguridad de pods en minikube

Pero aún nos quedan muchas cosas que ver, así que en la tercera parte del artículo continuaremos configurando la política de seguridad de pods en Kuberneters "like a boss"... mientras tanto.

Happy Hacking Hackers!!

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades. 

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

**************************************************************************************************

- Gestionar la política de seguridad de pods en Kubernetes “Like a Boss” (1 de 3)

- Gestionar la política de seguridad de pods en Kubernetes “Like a Boss” (2 de 3)

- Gestionar la política de seguridad de pods en Kubernetes “Like a Boss” (3 de 3)

**************************************************************************************************