Examen des journaux de service, de serveur d'API et de noeud worker

Les journaux d'audit vous permettent de mieux comprendre les opérations qui sont lancées par les utilisateurs de votre cluster, ce qui peut vous aider à traiter les incidents ou à signaler des problèmes de conformité avec les normes internes et de l'industrie.

Journaux d'audit de serveur d'API Kubernetes

Pour surveiller l'activité d'administration Kubernetes initiée par un utilisateur dans votre cluster, vous pouvez collecter et acheminer les événements transmis via votre serveur d'API Kubernetes vers IBM Cloud Logs ou un serveur externe.

Remarques et prérequis

Avant de définir une configuration d'audit d'API Kubernetes, reportez-vous aux informations suivantes :

Clusters VPC versions 4.15 et ultérieures: Les journaux d'audit utilisent le profil de politique d'audit Red Hat OpenShift default (pour la valeur par défaut) et WriteRequestBodies(pour la valeur verbeuse). Pour plus d'informations, voir Politique de journal d'audit.
Toutes les autres versions de cluster: Les journaux d'audit utilisent la règle openshift-audit dans le kube-samples référentiel.

Vous ne pouvez pas modifier la règle par défaut ou appliquer votre propre règle personnalisée.

Pour en savoir plus sur les journaux d'audit et le niveau de détail d' Kubernetes, consultez la documentation Kubernetes.
Un seul webhook d'audit peut être créé sur un cluster.
Vous devez disposer du rôle d'accès à la plateforme IAM Administrator IBM Cloud pour le cluster Red Hat OpenShift on IBM Cloud.

Pour commencer, suivez les instructions afin d'envoyer les journaux d'audit de l'API d' Kubernetes vers une ressource du réseau privé IBM Cloud.

Transfert des journaux d'audit de l'API Kubernetes vers Cloud Logs

Pour transférer les journaux d'audit à IBM Cloud Logs, vous pouvez créer un système d'audit Kubernetes à l'aide de l'image et du déploiement fournis.

L'exemple suivant utilise icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs l'image pour transférer les journaux vers IBM Cloud Logs. Si vous avez uniquement besoin d'une preuve de concept, vous pouvez ignorer l 'étape de configuration sécurisée. Pour une solution plus automatisée, configurez et maintenez votre propre image de transfert de journaux.

Auparavant, le protocole icr.io/ibm/ibmcloud-kube-audit-to-logdna était utilisé pour transférer les journaux. Cette image est obsolète et le support prendra bientôt fin. Mettez à jour votre configuration de transfert de journaux pour utiliser l' icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs.

Le système d'audit Kubernetes de votre cluster est constitué d'un webhook d'audit, d'un service de collecte de journaux et d'une application de serveur Web, et d'un agent de journalisation. Le webhook collecte les événements de serveur d'API Kubernetes à partir de votre maître de cluster. Le service de collecte de journaux est un service ClusterIP Kubernetes qui est créé à partir d'une image du registre IBM Cloud public. Ce service met à disposition une application web simple de type HTTP accessible uniquement sur le réseau du cluster. L'application de serveur Web analyse les données du journal à partir du webhook d'audit et crée chaque journal comme une ligne JSON unique. Enfin, l'agent de journalisation transfère les journaux de l'application du serveur web vers IBM Cloud Logs, où vous pouvez les consulter.

Avant de commencer: assurez-vous d'avoir pris connaissance des considérations et des prérequis, et de disposer du rôle d' IBM Cloudn d'accès à la plateforme IAM pour IBM Cloud Logs.

Ciblez le registre de conteneur global pour les images IBM Cloud publiques.
```
ibmcloud cr region-set global
```
Facultatif : pour plus d'informations sur l'image kube-audit, consultez icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs.
```
ibmcloud cr image-inspect icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs
```
Configurez votre kubeconfig pour accéder à votre cluster avec
```
ibmcloud ks cluster config -c CLUSTER
```

Créez un fichier de configuration nommé ibmcloud-kube-audit.yaml. Ce fichier de configuration crée un service de collecte de journaux et un déploiement qui récupère l'image icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs permettant de créer un conteneur de collecte de journaux.

apiVersion: v1
kind: List
metadata:
  name: ibmcloud-kube-audit
items:
  - apiVersion: v1
    kind: Namespace
    metadata:
      name: ibm-kube-audit
      labels:
        pod-security.kubernetes.io/enforce: restricted
        pod-security.kubernetes.io/enforce-version: latest
        pod-security.kubernetes.io/audit: restricted
        pod-security.kubernetes.io/audit-version: latest
        pod-security.kubernetes.io/warn: restricted
        pod-security.kubernetes.io/warn-version: latest
        security.openshift.io/scc.podSecurityLabelSync: "false"
  - apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ibmcloud-kube-audit
      namespace: ibm-kube-audit
      labels:
        app: ibmcloud-kube-audit
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: ibmcloud-kube-audit
      template:
        metadata:
          labels:
            app: ibmcloud-kube-audit
        spec:
          containers:
            - name: ibmcloud-kube-audit
              image: 'icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest'
              imagePullPolicy: Always
              ports:
                - containerPort: 3000
                - containerPort: 4443
              securityContext:
                allowPrivilegeEscalation: false
                runAsNonRoot: true
                capabilities:
                  drop:
                  - ALL
                seccompProfile:
                  type: RuntimeDefault
              volumeMounts:
                - mountPath: /certificates
                  name: certificates
                  readOnly: true
          volumes:
            - name: certificates
              secret:
                secretName: audit-webhook
                optional: true
  - apiVersion: v1
    kind: Service
    metadata:
      name: ibmcloud-kube-audit-service
      namespace: ibm-kube-audit
      labels:
        app: ibmcloud-kube-audit
    spec:
      selector:
        app: ibmcloud-kube-audit
      ports:
        - name: http
          protocol: TCP
          port: 80
          targetPort: 3000
        - name: https
          protocol: TCP
          port: 443
          targetPort: 4443
      type: ClusterIP
  - kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: ibmcloud-kube-audit
      namespace: ibm-kube-audit
    spec:
      podSelector:
        matchLabels:
          app: ibmcloud-kube-audit
      policyTypes:
      - Ingress
      ingress:
      - ports:
        - protocol: TCP
          port: 3000
        - protocol: TCP
          port: 4443
        from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              app: konnectivity-agent
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              app: vpn

Créez le déploiement dans l'espace de noms ibm-kube-audit de votre cluster.
```
kubectl apply -f ibmcloud-kube-audit.yaml
```

Attendez que le ibmcloud-kube-audit déploiement atteigne le statut Disponible.

kubectl wait --for condition=Available --namespace ibm-kube-audit --timeout 5m deploy/ibmcloud-kube-audit

Exemple de sortie

deployment.apps/ibmcloud-kube-audit condition met

Vérifiez que le service ibmcloud-kube-audit-service est déployé dans votre cluster.

kubectl get svc -n ibm-kube-audit -l app=ibmcloud-kube-audit

Exemple de sortie

NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
ibmcloud-kube-audit-service   ClusterIP   172.21.xxx.xxx   <none>        80/TCP           1m

Chiffrez le trafic en transit avec HTTPS. Si vous avez uniquement besoin d'un transfert de journaux d'audit de validation de concept, ignorez cette étape.
Vérifier l'état de l'autorité de certification. Si vos certificats approchent de leur date d'expiration, suivez les étapes pour effectuer une rotation de vos certificats.
```
ibmcloud oc cluster ca status -c CLUSTER
```

Enregistrez le certificate-authority du cluster dans le fichier cluster-ca.pem.

ibmcloud oc cluster ca get -c CLUSTER --output json | jq -r .caCert | base64 -D > cluster-ca.pem

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster. Préparez un kubeconfig basé sur un certificat et enregistrez-le dans kubeconfig.json. Veillez à spécifier --admin l'option pour télécharger les client-key``client-certificate données et sur votre ordinateur local. Ces données sont utilisées ultérieurement pour configurer le webhook d'audit.
```
ibmcloud oc cluster config --cluster CLUSTER --admin --output json > kubeconfig.json
```
Si le propriétaire du fichier kubeconfig est supprimé ou si ses droits d'accès sont révoqués, le serveur API Kubernetes ne pourra plus envoyer de journaux d'audit. Pour éviter ce scénario, nous vous recommandons d'utiliser un identifiant de service pour cette opération, car celui-ci est directement lié au compte et non à un utilisateur spécifique.

Extrayez le certificat client kubeconfig dans le fichier kubeconfig-cert.pem.

jq -r '.users[].user."client-certificate-data"' kubeconfig.json | base64 -D > kubeconfig-cert.pem

Extraire la clé client kubeconfig dans le fichier kubeconfig-key.pem.

jq -r '.users[].user."client-key-data"' kubeconfig.json | base64 -D > kubeconfig-key.pem

Configurez le webhook d'audit et spécifiez certificate-authority, client-certificateet client-key. Le certificate-authority a été récupéré à l'étape 10 et le client-certificate et client-key le ont été récupérés lors des deux étapes précédentes. Vous pouvez policy éventuellement configurer sur une autre valeur.

ibmcloud oc cluster master audit-webhook set \
    --cluster CLUSTER \
    --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/http:ibmcloud-kube-audit-service:http/proxy/post \
    --ca-cert cluster-ca.pem \
    --client-cert kubeconfig-cert.pem \
    --client-key kubeconfig-key.pem \
    --policy default

Si vous avez configuré HTTPS à l'étape 8, définissez remote-server sur httpsURL à la place :

https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post

Vérifiez que le webhook d'audit est créé dans votre cluster.

ibmcloud oc cluster master audit-webhook get --cluster CLUSTER

Exemple de sortie

Server:   https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/http:ibmcloud-kube-audit-service:http/proxy/post
Policy:   default

Appliquez le webhook à votre serveur d'API Kubernetes en actualisant le maître de cluster. Il peut s'écouler plusieurs minutes avant que le maître ne soit actualisé.
```
ibmcloud oc cluster master refresh --cluster CLUSTER
```
Pendant l'actualisation du maître, mettez à disposition une instance d'IBM Cloud Logs et déployez un agent de journalisation sur chaque noeud worker de votre cluster. L'agent de journalisation est requis pour acheminer les journaux de votre cluster vers le service IBM Cloud Logs. Si vous avez déjà configuré des agents de journalisation dans votre cluster, vous pouvez ignorer cette étape.

Afficher l'état du cluster et attendre que indique Master State updating, puis attendre l'état deployed. Cela peut prendre plusieurs minutes.

ibmcloud ks cluster get -c CLUSTER

Exemple de sortie

...
Master
Status:     Refresh in progress. (2 seconds ago)
State:      updating
...
Master
Status:     Ready (2 seconds ago)
State:      deployed

Une fois que l'actualisation du maître est terminée et que les agents de journalisation s'exécutent sur vos noeuds worker, vous pouvez afficher vos journaux d'audit d'API Kubernetes dans IBM Cloud Logs.

Une fois le webhook d'audit configuré dans votre cluster, vous pouvez surveiller les mises à jour de version de l'image ibmcloud-kube-audit-to-ibm-cloud-logs en exécutant ibmcloud cr image-list --include-ibm | grep ibmcloud-kube-audit-to-ibm-cloud-logs. Pour afficher la version de l'image qui s'exécute actuellement dans votre cluster, exécutez oc get pods | grep ibmcloud-kube-audit-to-ibm-cloud-logs pour rechercher le nom de pod d'audit et exécutez kubectl describe pod <pod_name> pour afficher la version de l'image. Mettez à jour le pod vers la dernière version disponible sur la balise actuelle avec kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit et attendez que les nouveaux pods soient disponibles avec kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit.

Gérez les mises à jour, renouvelez les certificats et cryptez les données en transit avec l' HTTPS

Quelques points importants à noter avant de préparer le transfert des journaux :

La balise icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest image bénéficie de mises à jour corrigeant les vulnérabilités et les bogues. Cependant, le déploiement doit être redémarré manuellement pour prendre en compte ces modifications. Utilisez kubectl rollout restart -n ibm-kube-audit deploy/ibmcloud-kube-audit pour récupérer la dernière image et redémarrer en douceur.
Ce déploiement est installé et géré manuellement. Le passage de ce déploiement à un autre peut entraîner une interruption du journal d'audit.
Le certificat généré au cours des étapes suivantes peut faire l'objet d'une rotation. La rotation nécessite des étapes manuelles pour remplacer le secret et redémarrer le déploiement.

Pour sécuriser le déploiement avec le cryptage en transit, une clé privée et un certificat TLS signé par le kube-apiserver sont nécessaires.

Après avoir appliqué le fichier YAML à l'étape 4, attendez que la ressource Service renseigne l'adresse IP du cluster. Enregistrez cela dans la variable shell $cluster_ip.

cluster_ip=$(
    kubectl wait \
        --for jsonpath='{.spec.clusterIP}' \
        --namespace ibm-kube-audit \
        --output jsonpath='{.spec.clusterIP}' \
        --timeout 5m \
        svc/ibmcloud-kube-audit-service
)

Générer une clé privée et l'enregistrer dans server.key
```
openssl genrsa -out server.key 4096
```

Générer un fichier de configuration de demande server-csr.conf de signature de certificat. Ceci est utilisé pour générer le certificat que Kubernetes signera.

cat <<EOF > server-csr.conf
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
CN = system:node:ibmcloud-kube-audit-service.ibm-kube-audit.svc
O = system:nodes
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = ibmcloud-kube-audit-service.ibm-kube-audit.svc.cluster.local
DNS.2 = ibmcloud-kube-audit-service.ibm-kube-audit.svc
IP.1 = ${cluster_ip}
EOF

Générer la charge utile de la demande de signature de certificat pour Kubernetes à signer.
```
openssl req -new -config server-csr.conf -key server.key -out server.csr
```

Insérez la charge utile dans une ressource CSR ( CertificateSigningRequest ) d' Kubernetes

kubectl apply -f - <<EOF
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: ibmcloud-kube-audit-service.ibm-kube-audit
spec:
  request: $(base64 < server.csr | tr -d '\n')
  signerName: kubernetes.io/kubelet-serving
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF

Approuver la demande

kubectl certificate approve ibmcloud-kube-audit-service.ibm-kube-audit

Attendez que le certificat soit signé

kubectl wait \
    --for jsonpath='{.status.certificate}' \
    --output go-template='{{.status.certificate | base64decode}}' \
    --timeout 5m \
    csr/ibmcloud-kube-audit-service.ibm-kube-audit > server.crt

Créer un secret à partir du certificat et de la clé privée

kubectl create secret tls \
    --cert server.crt \
    --key server.key \
    --namespace ibm-kube-audit \
    audit-webhook

Redémarrez le déploiement pour récupérer le nouveau secret.

kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

Attendez que les nouveaux pods soient disponibles

kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

Le webhook d'audit est désormais prêt à recevoir des événements via une connexion cryptée. Lors de la configuration du webhook d'audit dans la section Transfert des journaux d'audit de l'API d' Kubernetes s vers Cloud Logs, vous devez utiliser la version https de la URL--remote-server à la place :
```
https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post`
```

Transfert des journaux d'audit d'API Kubernetes à une ressource du réseau privé IBM Cloud

Transférez les journaux d'audit à une ressource autre que IBM Cloud Logs située en dehors du cluster et accessible sur le réseau privé IBM Cloud.

L'exemple suivant utilise l'image haproxytech/haproxy-alpine:2.6 pour transférer les journaux. Cette image est à des fins de démonstration uniquement et ne doit pas être utilisée dans des environnements de production. Pour une solution de production, configurez et gérez votre propre image de transfert de journaux.

Avant de commencer, assurez-vous d'avoir passé en revue les remarques et les prérequis.

Créez un nouveau répertoire kube-audit-forwarder et créez-y un fichier haproxy.cfg avec le contenu suivant. N'oubliez pas de remplacer <REMOTE-IP>:<REMOTE-PORT> dans le fichier par l'adresse IP et le port de votre consommateur de journal distant.
```
global
  log stdout format raw local0 info
defaults
  mode http
  timeout client 10s
  timeout connect 5s
  timeout server 10s
  timeout http-request 10s
  log global
frontend myfrontend
  bind :3000
  default_backend remotelogstash
# Use remote log consumer IP and port here
backend remotelogstash
  server s1 <REMOTE-IP>:<REMOTE-PORT> check
```
Si votre serveur de consommation de logs impose une connexion sécurisée ( TLS ), vous pouvez ajouter vos fichiers de certificats à ce répertoire et modifier la section backend dans haproxy.cfg pour utiliser ces fichiers. Pour plus d'informations, voir la documentation de HAProxy.

Créez une mappe de configuration à partir du contenu du répertoire kube-audit-forwarder.

kubectl create namespace ibm-kube-audit; kubectl create configmap -n ibm-kube-audit kube-audit-forwarder-cm --from-file=kube-audit-forwarder

Créez un fichier de configuration nommé kube-audit-forwarder-remote-private-ip.yaml. Ce fichier de configuration crée un déploiement et un service qui achemine les journaux d'audit du cluster vers l'adresse IP de la ressource distante via le réseau privé IBM Cloud.

kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    app: kube-audit-forwarder
  name: kube-audit-forwarder
  namespace: ibm-kube-audit
spec:
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: kube-audit-forwarder
  strategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: kube-audit-forwarder
    spec:
      containers:
      - image: haproxytech/haproxy-alpine:2.6
        imagePullPolicy: IfNotPresent
        name: haproxy
        volumeMounts:
        - name: config-volume
          mountPath: /usr/local/etc/haproxy/haproxy.cfg
          subPath: haproxy.cfg
      volumes:
      - name: config-volume
        configMap:
          name: kube-audit-forwarder-cm
---
apiVersion: v1
kind: Service
metadata:
  name: kube-audit-forwarder
  namespace: ibm-kube-audit
spec:
  selector:
    app: kube-audit-forwarder
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: kube-audit-forwarder
  namespace: ibm-kube-audit
spec:
  podSelector:
    matchLabels:
      app: kube-audit-forwarder
  policyTypes:
  - Ingress
  ingress:
  - ports:
    - protocol: TCP
      port: 3000
    from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: konnectivity-agent
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app: konnectivity-agent
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app: vpn

Si vous avez ajouté des fichiers de certificat à kube-audit-forwarder à l'étape précédente, n'oubliez pas de répertorier ces fichiers dans la section volumeMounts en tant que subPath.

Créez le déploiement et le service.

kubectl create -f kube-audit-forwarder-remote-private-ip.yaml

Vérifiez que le déploiement kube-audit-forwarder et le service sont bien déployés dans votre cluster.

kubectl get svc -n ibm-kube-audit

Exemple de sortie

NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
...
kube-audit-forwarder  ClusterIP   10.xxx.xx.xxx   <none>        80/TCP           1m

kubectl get deployment -n ibm-kube-audit

Exemple de sortie

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
...
kube-audit-forwarder   1/1     1            1           6m27s

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster. Veillez à spécifier l'option --admin permettant de télécharger les fichiers client-key et client-certificate sur votre ordinateur. Ces fichiers sont utilisés ultérieurement pour configurer le webhook d'audit.
```
ibmcloud oc cluster config --cluster CLUSTER --admin
```
Vérifier l'état de l'autorité de certification. Si vos certificats approchent de leur date d'expiration, suivez les étapes pour effectuer une rotation de vos certificats.
```
ibmcloud oc cluster ca status -c CLUSTER
```

Interrogez le certificate-authority du cluster et enregistrez-le dans un fichier.

 ibmcloud oc cluster ca get -c CLUSTER --output json | jq -r .caCert | base64 -D > CERTIFICATE_AUTHORITY

Affichez votre configuration actuelle en exécutant la commande oc config view et passez en revue la sortie pour client-certificate et client-key.

oc config view --minify

Exemple de sortie

clusters:
- cluster:
    ...
    ...
    client-certificate: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin.pem
    client-key: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin-key.pem

Configurez le webhook d'audit et spécifiez les certificate-authority, client-certificate et client-key que vous avez extraits dans les étapes 5 à 7.

ibmcloud oc cluster master audit-webhook set --cluster CLUSTER --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post --ca-cert CERTIFICATE_AUTHORITY --client-cert CLIENT_CERTIFICATE --client-key CLIENT_KEY [--policy default|verbose]

Vérifiez que le webhook d'audit est créé dans votre cluster.

ibmcloud oc cluster master audit-webhook get --cluster CLUSTER_NAME_OR_ID

Exemple de sortie

OK
Server:            https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post
Policy:            default

Appliquez le webhook à votre serveur d'API Kubernetes en actualisant le maître de cluster. L'actualisation du maître peut prendre plusieurs minutes.
```
ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID
```

Une fois la commande master refresh exécutée, les journaux sont envoyés à l'adresse IP privée de la ressource de consignation.

Journaux d'audit de noeud worker

Red Hat OpenShift on IBM Cloud utilise le composant Linux Audit System, auditd, pour surveiller et consigner l'activité sur les nœuds worker. Bien que l'audit des nœuds de travail soit activé par défaut, aucune donnée d'audit n'est disponible tant que vous n'avez pas configuré le transfert des journaux vers une instance d' IBM Cloud Logs ou un serveur externe.

Présentation de la configuration d'audit de noeud worker

Les journaux sont stockés dans le répertoire /var/log/audit sur les noeuds worker. Les journaux sont visibles dans IBM Cloud Logs ou sur votre serveur externe après que vous avez configuré l'acheminement des journaux.

Auditd collecte des journaux sur divers événements, notamment :

Appels système Linux (syscalls)
Refus SELinux
Modifications de la règle SELinux
Modifications logicielles via le programme d'installation de package yum
Opérations Systemd
Modifications d'utilisateurs et de groupes Linux
Modifications apportées à Netfilter
Connexions SSH

Configuration de l'acheminement des journaux pour les noeuds worker

Voir Acheminement des journaux vers une instance IBM Cloud Logs.

Journaux d'audit de service

Par défaut, Red Hat OpenShift on IBM Cloud génère et envoie des événements à IBM Cloud Logs. Pour voir ces événements, vous devez créer une instance IBM Cloud Logs. Pour plus d'informations, voir Evénements IBM Cloud Logs.

Affichage des alertes `AuditWebhookError`dans les clusters activés pour l'audit

Red Hat OpenShift on IBM Cloud La version clusters comporte une alerte AuditWebhookError qui se déclenche lorsque le webhook d'audit plante ou est supprimé.

Pour afficher l'alerte :

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Dans Red Hat OpenShift on IBM Cloud, sélectionnez la vue Administrateur.
Cliquez sur Observer > Fonction d'alerte > AuditWebhookError.
Pour créer une notification pour cette alerte, voir Envoi de notifications à des systèmes externes.

Examen des journaux de service, de serveur d'API et de noeud worker

Examen des journaux de service, de serveur d'API et de noeud worker

Journaux d'audit de serveur d'API Kubernetes

Remarques et prérequis

Transfert des journaux d'audit de l'API Kubernetes vers Cloud Logs

Gérez les mises à jour, renouvelez les certificats et cryptez les données en transit avec l' HTTPS

Transfert des journaux d'audit d'API Kubernetes à une ressource du réseau privé IBM Cloud

Journaux d'audit de noeud worker

Présentation de la configuration d'audit de noeud worker

Configuration de l'acheminement des journaux pour les noeuds worker

Journaux d'audit de service

Affichage des alertes AuditWebhookErrordans les clusters activés pour l'audit

Affichage des alertes `AuditWebhookError`dans les clusters activés pour l'audit