SupportConsoleDevelopersStart a trialContact

Chapter 8. Configuring the audit log policy

You can control the amount of information that is logged to the API server audit logs by choosing the audit log policy profile to use.

8.1. About audit log policy profiles

Audit log profiles define how to log requests that come to the OpenShift API server, the Kubernetes API server, and the OAuth API server.

OpenShift Container Platform provides the following predefined audit policy profiles:

ProfileDescription

Default

Logs only metadata for read and write requests; does not log request bodies except for OAuth access token requests. This is the default policy.

WriteRequestBodies

In addition to logging metadata for all requests, logs request bodies for every write request to the API servers (create, update, patch). This profile has more resource overhead than the Default profile. [1]

AllRequestBodies

In addition to logging metadata for all requests, logs request bodies for every read and write request to the API servers (get, list, create, update, patch). This profile has the most resource overhead. [1]

  1. Sensitive resources, such as Secret, Route, and OAuthClient objects, are never logged past the metadata level.

By default, OpenShift Container Platform uses the Default audit log profile. You can use another audit policy profile that also logs request bodies, but be aware of the increased resource usage (CPU, memory, and I/O).

8.2. Configuring the audit log policy

You can configure the audit log policy to use when logging requests that come to the API servers.

Prerequisites

  • You have access to the cluster as a user with the cluster-admin role.

Procedure

  1. Edit the APIServer resource: 

    $ oc edit apiserver cluster

  2. Update the spec.audit.profile field: 

      apiVersion: config.openshift.io/v1
  kind: APIServer
  metadata:
  ...
  spec:
    audit:
      profile: WriteRequestBodies 1
    1
    Set to Default, WriteRequestBodies, or AllRequestBodies. The default profile is Default.
  3. Save the file to apply the changes.

  4. Verify that a new revision of the Kubernetes API server pods has rolled out. This will take several minutes. 

    $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    Review the NodeInstallerProgressing status condition for the Kubernetes API server to verify that all nodes are at the latest revision. The output shows AllNodesAtLatestRevision upon successful update: 

    AllNodesAtLatestRevision
3 nodes are at revision 12 1
    1
    In this example, the latest revision number is 12.

    If the output shows a message similar to one of the following, this means that the update is still in progress. Wait a few minutes and try again.

    • 3 nodes are at revision 11; 0 nodes have achieved new revision 12
    • 2 nodes are at revision 11; 1 nodes are at revision 12
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.