Auditing mit Einschränkungen

Mit Einschränkungsobjekten des Policy Controllers können Sie Richtlinien für Ihre Kubernetes-Cluster durchsetzen. Um Ihre Richtlinien zu testen, können Sie Ihren Einschränkungen eine Erzwingungsaktion hinzufügen. Anschließend können Sie Verstöße in Einschränkungsobjekten und Logs ansehen.

Arten von Erzwingungsaktionen

Es gibt zwei Erzwingungsaktionen: deny und dryrun.

deny ist die Standard-Erzwingungsaktion. Diese Option wird automatisch aktiviert, selbst wenn Sie in Ihrer Einschränkung keine Erzwingungsaktion einfügen. Verwenden Sie deny, um zu verhindern, dass ein bestimmter Clustervorgang bei einem Verstoß auftritt.

Mit dryrun können Sie Verstöße Ihrer Regeln beobachten, ohne Transaktionen aktiv zu blockieren. Sie können damit testen, ob Ihre Einschränkungen wie gewünscht funktionieren, bevor Sie die aktive Erzwingung mit der Aktion deny aktivieren. Das Testen von Einschränkungen auf diese Weise kann Störungen verhindern, die durch eine falsch konfigurierte Einschränkung verursacht werden.

Erzwingungsaktionen hinzufügen

Sie können enforcementAction: deny oder enforcementAction: dryrun einer Einschränkung hinzufügen.

Die folgende Beispieleinschränkung audit.yaml fügt die Aktion dryrun hinzu.

#audit.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: user-must-be-3333
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    runAsUser:
      rule: MustRunAs
      ranges:
        - min: 3333
          max: 3333

Erstellen Sie die Einschränkung. Zum Beispiel wird kubectl apply -f verwendet:

kubectl apply -f audit.yaml

Audit-Ergebnisse anzeigen

Geprüfte Verstöße werden an die Einschränkungsobjekte angehängt und in die Logs geschrieben. Verstöße, die der Admission-Controller ablehnt, werden nicht in den Logs aufgeführt.

Audit-Ergebnisse in Einschränkungsobjekten anzeigen

Führen Sie den folgenden Befehl aus, um die Felder spec.status anzuzeigen und Verstöße gegen eine bestimmte Einschränkung aufzurufen.

kubectl get constraint-kind constraint-name -o yaml

Beispiel

Führen Sie den folgenden Befehl aus, um die Ausgabe der Einschränkung von audit.yaml aufzurufen:

kubectl get K8sPSPAllowedUsers user-must-be-3333 -o yaml

Die Ausgabe sieht in etwa so aus:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  creationTimestamp: "2020-05-22T01:34:22Z"
  generation: 1
  name: user-must-be-3333
  resourceVersion: "13351707"
  selfLink: /apis/constraints.gatekeeper.sh/v1beta1/k8spspallowedusers/user-must-be-3333
  uid: 5d0b39a8-9bcc-11ea-bb38-42010a80000c
spec:
  enforcementAction: dryrun
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Pod
  parameters:
    runAsUser:
      ranges:
      - max: 3333
        min: 3333
      rule: MustRunAs
 status:
  auditTimestamp: "2020-05-22T01:39:05Z"
  byPod:
  - enforced: true
    id: gatekeeper-controller-manager-6b665d4c4d-lwnz5
    observedGeneration: 1
 totalViolations: 5
  violations:
  - enforcementAction: dryrun
    kind: Pod
    message: Container git-sync is attempting to run as disallowed user 65533
    name: git-importer-86564db8cb-5r4gs
    namespace: config-management-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container manager is attempting to run as disallowed user 1000
    name: gatekeeper-controller-manager-6b665d4c4d-lwnz5
    namespace: gatekeeper-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container kube-proxy is attempting to run without a required securityContext/runAsUser
    name: kube-proxy-gke-fishy131-default-pool-7369b17c-cckf
    namespace: kube-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container kube-proxy is attempting to run without a required securityContext/runAsUser
    name: kube-proxy-gke-fishy131-default-pool-7369b17c-jnhb
    namespace: kube-system
  - enforcementAction: dryrun
    kind: Pod
    message: Container kube-proxy is attempting to run without a required securityContext/runAsUser
    name: kube-proxy-gke-fishy131-default-pool-7369b17c-xrd8
    namespace: kube-system

Audit-Ergebnisse in Logs anzeigen

Sie können Prüfberichte in Ihren Logs aufrufen. Weitere Informationen zu Logs finden Sie unter Audit-Logs verwenden.

Führen Sie den folgenden Befehl aus, um alle Policy Controller-Logs abzurufen:

kubectl logs -n gatekeeper-system -l gatekeeper.sh/system=yes

Die Audit-Ergebnisse enthalten "process":"audit" in den Logzeilen, sodass Sie die Ausgabe an einen anderen Befehl übergeben und nach diesen Zeilen filtern können. Beispielsweise können Sie jq verwenden, die JSON-Dateien parst und Ihnen die Möglichkeit gibt, einen Filter für einen bestimmten Logtyp festzulegen.

Beispiel für ein Audit-Ergebnis aus Logging:

{
"level":"info",
"ts":1590111401.9769812,
"logger":"controller",
"msg":"Container kube-proxy is attempting to run without a required securityContext/runAsUser",
"process":"audit",
"audit_id":"2020-05-22T01:36:24Z",
"event_type":"violation_audited",
"constraint_kind":"K8sPSPAllowedUsers",
"constraint_name":"user-must-be-3333",
"constraint_namespace":"",
"constraint_action":"dryrun",
"resource_kind":"Pod",
"resource_namespace":"kube-system",
"resource_name":"kube-proxy-gke-fishy131-default-pool-7369b17c-xrd8"
}

Nächste Schritte