Audit-policy file path for custom RKE2 clusters.

[tbernacchi]

According to the RKE2 documentation the audit-policy file path is defined in /etc/rancher/rke2/audit-policy.yaml

The policy is defined in /etc/rancher/rke2/audit-policy.yaml

After adapting the audit policy, RKE2 must be restarted to load the new configuration.

But when we created a custom RKE2 cluster (v1.22.13+rke2r1) using Rancher (2.6.6.), after everything it's up and running and the cluster it's green in the UI if you edit the .yaml of the cluster to enable audit-policy, the path of the file it's been written in /var/lib/rancher/rke2/etc/config-files/audit-policy-file.

Steps to reproduce:

• Create a custom cluster RKE2 (v1.22.13+rke2r1);
• After the cluster it's green up and running edit the cluster and paste the audit-police:

      audit-policy-file: |
        apiVersion: audit.k8s.io/v1
        kind: Policy
        rules:
          # Don't log these read-only URLs.
          - level: None
            nonResourceURLs:
              - '/healthz*'
              - '/logs'
              - '/metrics'
              - '/version'
              - '/swagger*'
          # Don't log events requests.
          - level: None
            resources:
              - group: ""
                resources:
                  - events
          # High-volume and low-risk, so drop them.
          - level: None
            resources:
              - group: ""
                resources:
                  - endpoints
                  - services
                  - services/status
            users:
              - 'system:kube-proxy'
            verbs:
              - watch
          - level: None
            resources:
              - group: ""
                resources:
                  - nodes
                  - nodes/status
            userGroups:
              - 'system:nodes'
            verbs:
              - get
          - level: None
            namespaces:
              - kube-system
            resources:
              - group: ""
                resources:
                  - endpoints
            users:
              - 'system:kube-controller-manager'
              - 'system:kube-scheduler'
              - 'system:serviceaccount:kube-system:endpoint-controller'
            verbs:
              - get
              - update
          - level: None
            resources:
              - group: ""
                resources:
                  - namespaces
                  - namespaces/status
                  - namespaces/finalize
            users:
              - 'system:apiserver'
            verbs:
              - get
          # Don't log HPA fetching metrics.
          - level: None
            resources:
              - group: metrics.k8s.io
            users:
              - 'system:kube-controller-manager'
            verbs:
              - get
              - list
          # Don't log noisy system lease events
          - level: None
            namespaces:
              - kube-system
              - kube-node-lease
            resources:
              - group: coordination.k8s.io
                resources:
                  - leases
            users:
              - 'system:kube-controller-manager'
              - 'system:kube-scheduler'
              - 'system:node'
            verbs:
              - get
              - update
          # Default level for all other requests.
          - level: Metadata
            omitStages:
              - RequestReceived
              - ResponseStarted

• Click in Save;
• After a while, you should see the /var/lib/rancher/rke2/etc/config-files/audit-policy-file as an output from ps -ef | grep -i audit

[brandond]

If you provide a custom audit policy via the Rancher UI, the audit config file gets deployed to a location that is managed by the Rancher System Agent. This is part of Rancher's provisioning framework and SHOULD NOT be covered in the RKE2 docs.

The RKE2 docs only cover the location of the default audit file if you enable a hardened profile with the --profile flag. The RKE2 docs do not - by design - cover Rancher-specific behavior, or how to manage things via the Rancher UI. This is what the Rancher docs are for.

Can you identify a location in the Rancher docs where you think the audit configuration documentation could be improved? I will also add that the location of this file on the nodes themselves shouldn't really matter to the end-user; if they provisioned and are managing the cluster through the Rancher UI, they should manage the file content via that same interface. They should not be poking at the nodes directly; any changes they make to that file on disk will be lost next time the agent reconciles the configuration. Why is knowing the path to this file important?

[gregsidelinger]

Knowing the path is not important, however the Rancher behavior of audit-policy-file should be documented in the Rancher docs as it is different then RKE2. Since for RKE2 it is the path to a file on the file system and for Rancher it is the contents of said audit file.