Kubewarden es un motor de políticas para Kubernetes. Su misión es simplificar la adopción de políticas como código. Dado que PodSecurityPolicy (PSP) está en desuso en Kubernetes 1.21, puede usar Kubewarden como reemplazo de las políticas de PSP.

El equipo de Kubewarden ha escrito un script que aprovecha la herramienta de migración escrita por  AppVia para migrar PSP automáticamente. La herramienta es capaz de leer YAML de PSP y puede generar las políticas equivalentes en muchos motores de políticas diferentes. Nuestro sencillo script migra sus PSP a sus políticas Kubewarden equivalentes.

En la siguiente sección, aprenderemos cómo realizar las siguientes tareas,

*. Instale la pila de Kubewarden
* . Hacer cumplir la política de control de admisión

Ahora agregue el gráfico de helm e instale kubewarden en un clúster de kubernetes existente. He usado el clúster de kubernetes RKE2 de SUSE Rancher en mi configuración.

La pila de Kubewarden está compuesta por los siguientes componentes:

• Un número arbitrario de ClusterAdmissionPolicyrecursos: así se definen las políticas dentro de Kubernetes
• Un número arbitrario de PolicyServerrecursos: este componente representa una implementación de un Kubewarden PolicyServer. Las políticas definidas por los administradores son cargadas y evaluadas por KubewardenPolicyServer
• Una implementación de kubewarden-controller: este es el controlador que monitorea los recursos e interactúa con los componentes ClusterAdmissionPolicyde KubewardenPolicyServer

Para poder crear Policies tendremos que instalar kubewarden-crds , kubewarden-controller y kubewarden-defaults

Paso 1 ) Instalación de Cert-manager

El gráfico de Kubewarden depende de cert-manager. Como es una dependencia, primero tendremos que instalar cert-manager.

Para instalar la última versión de cert-manager, en la interfaz de usuario del servidor de Rancher, haga clic en la esquina más a la izquierda cerca del logotipo de Rancher -> Inicio -> rke2-cluster1 -> icono de Kubectl.

Ejecute los siguientes comandos en el shell de Kubectl:

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml

Debería ver una salida similar a la siguiente captura de pantalla,

$ kubectl wait –for=condition=Available deployment –timeout=2m -n cert-manager –all

Debería ver una salida similar a la siguiente captura de pantalla,

Ahora hemos implementado correctamente Certmanager en nuestro clúster. El siguiente paso sería instalar kubewarden stack.

Paso 2) Implementar la pila de Kubewarden

Los siguientes gráficos deben instalarse dentro del kubewardenespacio de nombres en su clúster de Kubernetes:

• kubewarden-crds, que registrará las Definiciones de recursos personalizados ClusterAdmissionPolicyyPolicyServer

• kubewarden-controller, que instalará el controlador Kubewarden

• kubewarden-defaults, que creará un PolicyServerrecurso llamado default. También puede instalar un conjunto de políticas recomendadas para proteger su clúster aplicando algunas de las mejores prácticas conocidas.

Abra el shell de Kubectl. Agregue el gráfico de timón de kubewarden usando el siguiente comando,

$ helm repo agregue kubewarden https://charts.kubewarden.io

La pila de Kubewarden se puede implementar desde el gráfico de timón superior. Copie y pegue los siguientes comandos en el shell de kubectl,

 $ helm install –wait -n kubewarden –create-namespace kubewarden-crds kubewarden/kubewarden-crds

 $ helm install –wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller

 $ helm install –wait - n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

Espere hasta que vea un resultado similar a la siguiente captura de pantalla.

Ahora hemos implementado la pila de Kubewarden. El siguiente paso es implementar políticas reales.

Paso 3 ) Hacer cumplir la política de control de admisión para evitar el ataque de suplantación de identidad ARP

Una vez que tenga la instancia de Kubewarden en ejecución, es hora de implementar algunas políticas para reemplazar el objeto PodSecurityPolicy. El recurso ClusterAdmissionPolicy es el núcleo de la pila de Kubewarden. Este recurso define cómo las políticas evalúan las solicitudes.

Hacer cumplir las políticas es la operación más común que realizará un administrador de Kubernetes. Puede declarar tantas políticas como desee, y cada política tendrá como objetivo uno o más recursos específicos de Kubernetes (es decir, pods, recursos personalizados). También especificará el tipo de operación(es) que se aplicará(n) a los recursos de destino. Las operaciones disponibles son CREAR, ACTUALIZAR, ELIMINAR y CONECTAR.

Kubernetes conecta de forma predeterminada todos los contenedores que se ejecutan en el mismo nodo (incluso si pertenecen a diferentes espacios de nombres) hasta la capa 2 (ethernet). Esto permite que los contenedores maliciosos realicen un ataque de suplantación de identidad ARP a los contenedores en el mismo nodo y capturen su tráfico.

Para evitar este tipo de ataque de suplantación de ARP, es importante no permitir la capacidad NET_RAW . La política de Kubewarden psp-capabilities controla las capacidades de contenedor. En el siguiente ejemplo, puede ver la capacidad NET_RAW en la sección required_drop_capabilities. Estas son capacidades que deben eliminarse de los contenedores y se eliminan del conjunto predeterminado.

Cree un archivo yaml clusteradmissionpolicy.yaml conpsp-capabilities kubewarden policy (que reemplaza al PSP anterior) debajo del contenido y guárdelo.

apiVersion: policy.kubewarden.io/v1alpha2
tipo: AdmissionPolicy
metadatos:
     nombre: drop-cap-net-raw
     namespace:
especificación predeterminada:
    policyServer:
    módulo predeterminado: registration://ghcr.io/kubewarden/policies/psp-capabilities:v0 .1.7
    reglas:
    – apiGroups: [“”]
      apiVersions: [“v1”]
      recursos:
      – pods
      – operaciones de implementación
      :
      – CREAR
      – ACTUALIZAR
   mutación:
   configuración verdadera: capacidades_descartadas_requeridas
       :
       – NET_RAW

Una vez implementado, debería ver una salida similar a la siguiente captura de pantalla,

Ahora vamos a crear un archivo de manifiesto bcisle15default.yamlcon el siguiente contenido y guardarlo y ejecutarlo,

apiVersion: apps/v1
tipo: Implementación
metadatos:
      nombre: bci-sle15
      etiquetas:
          aplicación: sle15
especificaciones:
     réplicas: 1
     estrategia:
        tipo: RollingUpdate
     selector:
        matchLabels:
             aplicación: sle15
     plantilla:
        metadatos:
              etiquetas:
                  aplicación: sle15
        especificaciones:
            contenedores:
            – nombre:
            imagen sle15: registration.suse.com/suse/sle15:latest
            imagePullPolicy: Comando IfNotPresent
            : ['sh', '-c', 'echo Container 1 is Running; dormir 3600']

Este pod debe tener la capacidad NET_RAW habilitada de forma predeterminada, ya que hereda el mismo archivo . Pero dado que hemos habilitado la política drop-cap-net-raw , esta capacidad debe eliminarse. Puede verificar esto iniciando sesión en este pod bci-sle15 y ejecutando los siguientes comandos,

$ zypper install -y libcap-progs
$ capsh –decode=$( cat /proc/$$/status | grep CapEff | cut -d : -f 2 | xargs )

Puede ver una salida similar a la siguiente captura de pantalla. Puede ver que las NET_RAWcapacidades se han ido/caído en el pod, debido a la aplicación de la política de admisión en Kubewarden)

Puede reemplazar las políticas de PSP existentes con la política de Kubewarden correspondiente enumerada en este centro de políticas.

https://artifacthub.io/packages/search?kind=13&sort=relevance&page=1