Guide de configuration de l’audit Kubernetes sur Prisma SaaS.

• Reportez-vous à la documentation Kubernates Audting
• Accédez à « Configurer le serveur » pour faire référence aux étapes fournies pour configurer le APIbackend du webhook d’audit
• Sur la console Compute, accédez à Defend > Access > Kubernetes > Accéder aux paramètres
• Notez que sur la console, après avoir cliqué sur l’option « Aller aux paramètres » pour trouver l’URL du webhook requise pour la configuration, les paramètres sont vides et sans url de webhook présente. Reportez-vous à l’image ci-dessous pour vous rapporter à l’explication:

• Prisma Cloud Compute (déploiement SaaS)
• Kubernetes (moteur Google Kubernetes)
• Kubernetes (Elastic Kubernetes Service et Azure Kubernetes Service)

• Selon les notes de publication pour Prisma Cloud Compute version 21.08.514
• Supprime la prise en charge de la configuration d’audit dynamique de Kubernetes, qui était déconseillée dans Kubernetes 1.19. La configuration d’audit dynamique était auparavant utilisée dans Prisma Cloud l’audit Kubernetes. Prisma Cloud L’audit Kubernetes utilise désormais le backend webhook standard.

• Chemin d’accès à la console » URL (Calcul / Gestion / Système / Utilitaires)
• export console= API Token (Calcul / Gérer / Système / Utilitaires)
• export token= <API Token>
• Les utilitaires suivants doivent être installés :
  • boucle
  • Jq
  • Openssl
  • kubectl (kubectl)
  • Firefox
  • A Méthode prise en charge pour la mise à jour des manifestes kube-apiserver. Cela se fait généralement en éditant /etc/kubernetes/manifests/kube-apiserver.manifest sur les nœuds maîtres, mais peut dépendre de la distribution Linux/K8s.

TASK FLOW:

1. Vérifier que l’audit Kubernetes est activé dans Prisma Cloud Compute
2. Générer un webhook URL
3. Téléchargez Certificate Chain et convertissez-la en base64
4. Générer audit-webhook.yaml
5. Ajouter un webhook et policy une configuration à tous les nœuds maîtres
6. Mettre à jour les manifestes kube-apiserver sur tous les nœuds maîtres
7. Test pour vérifier si le programme d’installation fonctionne correctement

Étape 1 : Vérifier que l’audit Kubernetes est activé dans Prisma Cloud Calculer.
Accédez à Compute / Access / Kubernetes et vérifiez que l’audit Kubernetes est activé et dispose d’une règle que vous allez tester (Exec ou attacher à un pod est le plus facile)
 

 
Étape 2: Générer un webhook URL

Pour générer le webhook, vous devez générer un suffixe de webhook et l'ajouter au point de terminaison '/api/v1/kubernetes/webhook URL/'

Exécutez la commande suivante pour créer une variable webhook :

 

Étape 3: Téléchargez la chaîne de certificats et convertissez-la en base64

Téléchargez la chaîne de certificats et exportez-la vers base64

• Ouvrez Firefox et accédez au 'Chemin vers la console' URL
• Cliquez sur l’icône Certificat suivie de la flèche Connexion sécurisée dans la barre d’outils :

• Cliquez sur Plus d’informations

• Certificat De vue de clic

• Faites défiler jusqu’à Divers et téléchargez la PEM chaîne

• Dans votre terminal, cd dans le dossier dans lequel la PEM chaîne a été téléchargée.
• Exécutez la commande suivante pour enregistrer la PEM chaîne en tant que variable codée en base64 :

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

Étape 4: Générer audit-webhook.yaml

Générer les fichiers audit-webhook.yaml et audit-policy.yaml requis pour envoyer des événements d’audit à Prisma Cloud

• Exécutez la commande suivante pour générer 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

• Exécutez la commande suivante pour générer l’audit policypar défaut :

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

Étape 5 : Ajouter le webhook et policy la configuration à tous les nœuds maîtres

Vous devez ensuite ajouter les fichiers d’audit à tous les nœuds maîtres dans un fichier accessible à kube-apiserver.

• Exécutez la commande suivante pour afficher les volumes hôtes accessibles à kube-apiserver :

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

• Notez le chemin d’accès le plus logique pour placer les YAML fichiers générés précédemment. Par exemple, cela m’a renvoyé les chemins d’accès suivants :

/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 J’ai déterminé que le chemin /srv/kubernetes/kube-apiserver était le plus logique pour moi.

• SCP audit-webhook.yaml et audit-.yaml à chaque nœud maître dans le chemin que vous avez sélectionné (/srv/kubernetes/kube-apiserverpolicy dans mon cas).

Étape 6 : Mettre à jour les manifestes kube-apiserver sur tous les nœuds maîtres

Cette étape variera en fonction de la distribution k8s, alors confirmez avec le fournisseur / docs que c’est la bonne façon avant d’aller de l’avant.

• Recherchez le fichier kube-apiserver.manifest
• Ouvrez kube-apiserver.manifest dans un éditeur de texte et recherchez une section qui ressemble à ceci :

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

• Ajoutez les options suivantes à la liste de commandes sous '- kube-apiserver' et assurez-vous de mettre à jour le chemin en rouge vers le chemin que vous avez sélectionné précédemment.

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

• La mise à jour kube-apiserver.manifest devrait ressembler à ceci lorsque vous avez terminé :

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

• Remarque : une option audit-log-path est activée dans votre fichier MUST manifeste kube-apiserver afin d’activer la journalisation d’audit.
• Une fois que vous avez enregistré le fichier manifeste, le kube-apiserver devrait redémarrer - cela peut prendre environ 30 secondes et vous risquez de perdre temporairement l’accès au APIfichier .

• Effectuez un test par rapport à l’une des règles par défaut pour vérifier qu’elle fonctionne.

• Exécutez un exec dans un conteneur pour tester l’une des règles par défaut :

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

• Vérifiez la Prisma Cloud console dans Compute / Monitor / Events / Kubernetes Audits

Dépannage

Si le pod kube-apiserver ne parvient pas à redémarrer, cela signifie généralement qu’il y a un problème avec votre fichier manifeste. Vous devrez résoudre ce problème, mais le processus dépend de la distribution kubernetes. A Peu de méthodes possibles sont:

• journalctl --unit kubelet
• Journaux Docker <conteneur>
• Journaux crictl <conteneur>

Si la Prisma Cloud console ne parvient pas à afficher les journaux d’audit, les journaux kube-apiserver fournissent généralement un indice :

• kubectl enregistre kube-apiserver-<reste du nom du pod>

• Audit Kubernetes
• https://kubernetes.io/docs/tasks/debug-application-cluster/audit/