1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Audit
    6. Kubernetes auditing
    End-of-Life (EoL)

    Kubernetes auditing

    The Kubernetes auditing system records the activities of users, administrators, and other components, that have affected the cluster. Prisma Cloud can ingest, analyze, and alert on security-relevant events. Write custom rules or leverage Prisma Cloud Labs prewritten rules to assess the incoming audit stream and surface suspicious activity.
    To get started, configure your cluster to forward audits to Prisma Cloud. Prisma Cloud supports both Google Kubernetes Engine (GKE) and self-managed clusters.

    Rule library

    Custom rules are stored in a central library, where they can be reused. Besides your own rules, Prisma Cloud Labs also distributes rules via the Intelligence Stream. These rules are shipped in a disabled state by default. You can review, and optionally apply them at any time.
    Your Kubernetes audit policy is defined in
    Defend > Access > Kubernetes
    , and formulated from the rules in your library. There are four types of rules, but the only one relevant to the audit policy is the kubernetes-audit type. Custom rules are written and managed in Console under
    Defend > Custom configs > Runtime
     with an online editor. The compiler checks for syntax errors when you save a rule.

    Expression grammar

    Expressions let you examine contents of a Kubernetes audit. Expressions have the following grammar:
    • term
       --
      integer | string | keyword | event | '(' expression ')' | unaryOp term
    • in
       --
      '(' integer | string (',' integer | string)*)?
    • op
       --
      and | or | > | < | >= | ⇐ | = | !=
    • unaryOp
       --
      not
    • keyword
       --
      startswith | contains
    • string
       --
      Strings must be enclosed in double quotes
    • integer
       --
      int
    • event
       --
      process, file system, or network

    Kubernetes audit events

    When Prisma Cloud receives an audit, it is assessed against your policy. Like all policies in Prisma Cloud, rule order is important. Rules are processed top to bottom, and processing stops at the first match. When a rule matches, an alert is raised.
    Write rules to surface audits of interest. Rules are written with the jpath function. The jpath function extracts fields from JSON objects, which is the format of a Kubernetes audit. The extracted string can then be compared against strings of interest. The primary operators for jpath expressions are '=', 'in', and 'contains'. For non-trivial examples, look at the Prisma Cloud Lab rules.
    The argument to jpath is a single string. The right side of the expression must also be a string. A basic rule with a single jpath expressions has the following form:
    jpath("path.in.json.object") = "something"
    Let’s look at some examples using the following JSON object as our example audit.
    {
   "user":{
      "uid":"1234",
      "username":"some-user-name",
      "groups":[
         "group1",
         "group2"
      ]
   },
   "stage":"ResponseComplete"
}
    To examine user’s UID, use the following syntax. This expression evaluates to true.
    jpath("user.uid") = "1234"
    To examine username, use the following syntax:
    jpath("user.username") = "some-user-name"
    To examine the stage field, use the following syntax:
    jpath("stage") = "ResponseComplete"
    To examine the groups list field, use the following syntax:
    jpath("user.groups") contains "group1"
    Or alternatively:
    jpath("user.groups") in ("group1","group2")

    Integrating with self-managed clusters

    Prisma Cloud supports any self-managed cluster based on Kubernetes version 1.13, or later. You can deploy clusters with any number of tools, including kubeadm.
    Prerequisites:
     You’ve already deployed a Kubernetes cluster.

    Configure the API server

    Configure the API server to forward audits to Prisma Cloud.
    To configure the audit webhook backend:
    • Create an audit policy file that specifies the events to record and the data events should contain.
    • Create a configuration file that defines the backend details and configurations.
    • Update the API server config file to point to your audit policy and configuration files.
    If your API server runs as a pod, then the audit policy and configuration files must be placed in a directory mounted by the API server pod. Either place the files in an already mounted directory, or create a new one.
    If flags/objects related to AuditSink/dynamic auditing were previously added to your API server configuration, remove them. Otherwise, this setup won’t work.
    1. Specify the audit policy.
      Create a file called audit-policy.yaml with the following recommended policy:
      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
      More details can be found here.
    2. Create a configuration file.
      Create a configuration file named audit-webhook.yaml. For the server address, <console_url>, go to
      Defend > Access > Kubernetes > Go to settings
      . The address string can be found in spec.webhook.clientConfig.url.
      apiVersion: v1
kind: Config
preferences: {}
clusters:
- name: <cluster_name>
  cluster:
    server: <console_url> # compute console endpoint as stated above
contexts:
- name: webhook
  context:
    cluster: <cluster_name>
    user: kube-apiserver
current-context: webhook
    3. Move the config files into place.
      Move both audit-policy.yaml and audit-webhook.yaml to a directory that holds your API server config files. If the API server runs as a pod, move the files to a directory that is accessible to the pod. Accessible directories can be found in the API server config file under mounts.
      Alternatively, create a new directory and add it to mounts. For more information, see here.
    4. Add flags.
      Configure the API server to use the policy and configuration files you just created. Add the following flags to the API server config file:
      spec:
  containers:
  - command:
    # Existing flags
    ...
    # New flags for Prisma Cloud:
    - --audit-policy-file=<PATH-TO-API-SERVER-CONFIG-FILES>/audit-policy.yaml
    - --audit-webhook-config-file=<PATH-TO-API-SERVER-CONFIG-FILES>/audit-webhook.yaml
      When changing the kube-apiserver config file, the API server automatically restarts. It can take a few minutes for the API server to resume operations.

    Configure your cluster to forward audits to Prisma Cloud

    Configure your cluster to forward audits to Prisma Cloud.
    1. Open Console.
    2. Go to
      Defend > Access > Kubernetes
      .
    3. Set
      Kubernetes auditing
       to
      Enabled
      .
    4. Click
      Go to settings
      .
      1. Set
        Deployment type
         to
        Default
        .
      2. Copy the webhook URL. This where your cluster will send audits.
    5. Configure the webhook in the cluster with an AuditSink object.
      To route audits over HTTP:
       Create a file named auditsink.yaml. Paste the following listing into it. Replace WEBHOOK-URL with the URL you copied from Prisma Cloud Console.
      apiVersion: auditregistration.k8s.io/v1alpha1
kind: AuditSink
metadata:
  name: twistlock-sink
spec:
  policy:
    level: Request
    stages:
    - ResponseComplete
  webhook:
    throttle:
      qps: 10
      burst: 15
    clientConfig:
      url: "WEBHOOK-URL"
      To route audits over HTTPS:
       Create a file named auditsink.yaml. Paste the following listing into it. Replace WEBHOOK-URL with the URL you copied from Prisma Cloud Console. Replace CA-BUNDLE with a PEM-encoded CA bundle, which the cluster can use to validate Prisma Cloud’s certificate.
      apiVersion: auditregistration.k8s.io/v1alpha1
kind: AuditSink
metadata:
  name: twistlock-sink
spec:
  policy:
    level: Request
    stages:
    - ResponseComplete
  webhook:
    throttle:
      qps: 10
      burst: 15
    clientConfig:
      url: "WEBHOOK-URL"
      caBundle: CA-BUNDLE
    6. Create the AuditSink object in your cluster.