Guía para configurar la auditoría de Kubernetes en Prisma SaaS.

• Consulte la documentación de Kubernates Audting
• Navegue hasta "Configurar el servidor" para consultar los pasos proporcionados para configurar el APIbackend de webhook de auditoría
• En Compute Console, vaya a Defender > Access > Kubernetes > Vaya a configuración
• Tenga en cuenta que en la consola, después de hacer clic en la opción "Ir a la configuración" para encontrar la url del webhook requerida para la configuración, la configuración está vacía y sin la url del webhook presente allí. Consulte la imagen a continuación para relacionarse con la explicación:

• Prisma Cloud Proceso (implementación de SaaS)
• Kubernetes (Motor de Google Kubernetes)
• Kubernetes (Elastic Kubernetes Service y Azure Kubernetes Service)

• De acuerdo con Prisma Cloud las notas de la versión de Compute 21.08.514
• Elimina la compatibilidad con la configuración de auditoría dinámica de Kubernetes, que quedó obsoleta en Kubernetes 1.19. La configuración de auditoría dinámica se usaba anteriormente en Prisma Cloud la auditoría de Kubernetes. Prisma Cloud La auditoría de Kubernetes ahora utiliza el backend de webhook normal.

• Ruta a la consola' URL (Cómputo / Administrar / Sistema / Utilidades)
• export console= API Token (Compute / Manage / System / Utilities)
• export token= <API token>
• Es necesario instalar las siguientes utilidades:
  • Enrollamiento
  • jq
  • Openssl
  • kubectl
  • Firefox
  • A Método admitido para actualizar los manifiestos kube-apiserver. Esto se hace normalmente editando /etc/kubernetes/manifests/kube-apiserver.manifest en nodos maestros, pero puede depender de la distribución Linux/K8s.

TASK FLOW:

1. Verificar que Kubernetes Auditing esté habilitado en Prisma Cloud Compute
2. Generar Webhook URL
3. Descargar Certificate Chain y convertir a base64
4. Generar audit-webhook.yaml
5. Agregar webhook y policy configuración a todos los nodos maestros
6. Actualizar manifiestos kube-apiserver en todos los nodos maestros
7. Pruebas para comprobar si la configuración funciona correctamente

Paso 1: Verificar que Kubernetes Auditing esté habilitado en Prisma Cloud Calcular.
Vaya a Compute / Access / Kubernetes y verifique que la auditoría de Kubernetes esté habilitada y tenga una regla que probará (Exec o adjuntar a un pod es lo más fácil)
 

 
Paso 2: Generar Webhook URL

Para generar el webhook, debe generar un sufijo de webhook y agregarlo al punto final '/api/v1/kubernetes/webhook URL/'

Ejecute el siguiente comando para crear una variable webhook:

 

Paso 3: Descargar Certificate Chain y convertir a base64

Descargue la cadena de certificados y expórtela a base64

• Abra Firefox y vaya a la 'Ruta a la consola' URL
• Haga clic en el icono Certificado seguido de la flecha Conexión segura en la barra de herramientas:

• Haga clic en Más información

• Haga clic en Ver certificado

• Desplácese hacia abajo hasta Varios y descargue la PEM cadena

• En su terminal, cd a la carpeta en la que se descargó la PEM cadena.
• Ejecute el siguiente comando para guardar la PEM cadena como una variable codificada en base64:

export cacerts=$(openssl base64 -in cloud-twistlock-com-chain.pem -A)

Paso 4: Generar audit-webhook.yaml

Generar audit-webhook.yaml y audit-policy.yaml necesarios para enviar eventos de auditoría a Prisma Cloud

• Ejecute el siguiente comando para generar audit-webhook.yaml:

cat <<EOF > audit-webhook.yaml

apiVersion: v1
kind: Config
preferences: {}
clusters:
- name: audit-cluster
  cluster:
    server: $webhookurl
    certificate-authority-data: $cacerts
contexts:
- name: webhook
  context:
    cluster: audit-cluster
    user: kube-apiserver
current-context: webhook
EOF

• Ejecute el siguiente comando para generar la auditoría policypredeterminada:

cat <<EOF > audit-policy.yaml

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Generate audit events only for ResponseComplete or panic stages of a request.
omitStages:
  - "RequestReceived"
  - "ResponseStarted"
rules:
  # Audit on pod exec/attach events
  - level: Request
    resources:
    - group: ""
      resources: ["pods/exec", "pods/attach"]

  # Audit on pod creation events
  - level: Request
    resources:
    - group: ""
      resources: ["pods"]
    verbs: ["create"]

  # Audit on changes to the twistlock namespace (defender daemonset)
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    namespaces: ["twistlock"]

  # Default catch all rule
  - level: None
EOF

Paso 5: Agregar webhook y policy configuración a todos los nodos maestros

A continuación, debe agregar los archivos de auditoría a todos los nodos maestros en un archivo accesible para kube-apiserver.

• Ejecute el siguiente comando para ver los volúmenes de host accesibles para kube-apiserver:

kubectl get pods -n kube-system kube-apiserver-<rest of pod name> -o jsonpath='{range .spec.volumes[*]}{.hostPath.path}{"\n"}{end}'

• Anote una ruta de acceso que tenga más sentido para colocar los YAML archivos que se generaron anteriormente. Por ejemplo, esto me devolvió las siguientes rutas:

/var/log/kube-apiserver.log
/etc/ssl
/etc/pki/tls
/etc/pki/ca-trust
/usr/share/ssl
/usr/ssl
/usr/lib/ssl
/usr/local/openssl
/var/ssl
/etc/openssl
/etc/kubernetes/in-tree-cloud.config
/srv/kubernetes/ca.crt
/srv/kubernetes/kube-apiserver
/srv/sshproxy
/etc/kubernetes/kube-apiserver-healthcheck/secrets

I Determiné que la ruta /srv/kubernetes/kube-apiserver tenía más sentido para mí.

• SCP audit-webhook.yaml y audit-.yaml a cada nodo maestro en la ruta que haya seleccionado (/srv/kubernetes/kube-apiserverpolicy en mi caso).

Paso 6: Actualizar los manifiestos kube-apiserver en todos los nodos maestros

Este paso variará dependiendo de la distribución de k8s, así que confirme con el proveedor / docs que esta es la forma correcta antes de seguir adelante.

• Busque el archivo kube-apiserver.manifest
• Abra kube-apiserver.manifest en un editor de texto y busque una sección similar a esta:

spec:

  containers:
  - command:
    - kube-apiserver
    - --admission-control-config-file=/etc/kubernetes/extra-config/admission-control-config.yaml
    - --advertise-address=X.X.X.X
    - --allow-privileged=true
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    - --audit-log-path=/var/log/kubernetes/kube-apiserver.log

• Agregue las siguientes opciones a la lista de comandos en '- kube-apiserver' y asegúrese de actualizar la ruta en rojo a la ruta que seleccionó anteriormente.

--audit-policy-file=/srv/kubernetes/kube-apiserver/audit-policy.yaml
--audit-webhook-config-file=/srv/kubernetes/kube-apiserver/audit-webhook.yaml

• La actualización kube-apiserver.manifest debería verse así cuando haya terminado:

spec:

  containers:
  - command:
    - kube-apiserver
    - --admission-control-config-file=/etc/kubernetes/extra-config/admission-control-config.yaml
    - --advertise-address=X.X.X.X
    - --allow-privileged=true
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    - --audit-policy-file=/srv/kubernetes/kube-apiserver/audit-policy.yaml
    - --audit-webhook-config-file=/srv/kubernetes/kube-apiserver/audit-webhook.yaml
    - --audit-log-path=/var/log/kubernetes/kube-apiserver.log

• Nota: Su archivo MUST de manifiesto kube-apiserver tiene habilitada una opción audit-log-path para activar el registro de auditoría.
• Una vez que guarde el archivo de manifiesto, debería hacer que el kube-apiserver se reinicie, esto puede tardar unos 30 segundos en completarse y puede perder temporalmente el APIacceso al archivo .

• Realice una prueba con una de las reglas predeterminadas para comprobar que funciona.

• Ejecute un exec dentro de un contenedor para probar una de las reglas predeterminadas:

kubectl exec <pod> -it -- /bin/sh

• Compruebe la Prisma Cloud consola en Compute / Monitor / Events / Kubernetes Audits

Solución de problemas

Si el pod kube-apiserver no se inicia de forma de respaldo, normalmente eso significa que hay un problema con el archivo de manifiesto. Deberá solucionar este problema, sin embargo, el proceso depende de la distribución de kubernetes. A Algunos métodos posibles son:

• journalctl --Unidad Kubelet
• Registros de Docker <contenedor>
• CRICTL Logs <contenedor>

Si la Prisma Cloud consola no muestra los registros de auditoría, normalmente los registros kube-apiserver proporcionarán una pista:

• kubectl registra kube-apiserver-<resto del nombre del pod>

• Auditoría de Kubernetes
• https://kubernetes.io/docs/tasks/debug-application-cluster/audit/