Enabling user access and other pod-related logs in Container environment

Last published : Jun 12, 2026
OpenShift and Kubernetes clusters have an in-built logging mechanism. You can configure the /etc/kubernetes/manifests/kube-apiserver.yamlto include the following types of logs.
Note: You must enableEO_COMPLIANCEfor your InfoScale deployment first. Edit the licensing operator deployment and sds-operator deployment. Run the following commandsoc/kubectl edit deployment -n infoscale-vtas \<deployment_name\>andoc/kubectl edit deployment -n infoscale-vtas infoscale-licensing-operator. Ensure that you updateEO_COMPLIANCEhere to enabled as under. name: EO_COMPLIANCE value: enabled If you want to enableEO_COMPLIANCEon an OpenShift cluster by using OLM, runoc edit subscription infoscale-sds-operator -n infoscale-vtasand add the following to spec: config: env: - name: EO_COMPLIANCE value: enabled If DR is configured, runoc/kubectl edit deployment -n infoscale-vtas infoscale-dr-managerand enableEO_COMPLIANCE. After you edit and save the sds-operator deployment, the InfoScale sds operator restarts automatically. You have to manually restart the other pods. Ensure that you restart one pod at a time. After a restarted pod is in a 'Ready' state, restart the next pod.
  • Software upgrades and configuration file changes
  • System (Virtual or Physical) boot and halt
  • Process launches
  • Non-normal process exits
  • SELinux policy violations
  • System login attempts
  • Services starts and stops
  • Container starts and exits
You can thus log all events related to InfoScale pods, secrets and config maps.
Bourne shell is deprecated. You can invoke Bash in sh mode, where command logging is not supported.
Note: After you configure these files, API server must be restarted. Hence, the server experiences a downtime. Ensure that you inform about the downtime to the user community. If the files are not correctly configured, the API server might not restart. The configuration must be performed by a competent Storage Administrator.
Add the following code to /etc/kubernetes/manifests/kube-apiserver.yamlto log all user login attempts to the InfoScale pods. The user name, time, and whether the attempt is successful or not is logged.
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
rules
# Log pod/exec requests at RequestResponse level
- level: RequestResponse
namespaces: ["infoscale-vtas"]
resources:
- group: ""
resources: ["pods/exec"]
# Log everything else at Metadata level
- level: Metadata
omitStages:
- "RequestReceived"
Similarly, add the following code to log pods creation and deletion, config map changes, and secrets changes.
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- "RequestReceived"
rules:
#Log the Metadata of Pod changes in given namespace
- level: Metadata
resources:
- group: ""
resources: ["pods"]
verbs: ["create", "patch", "update", "delete"]
namespaces: [""] #Fill namespace
#Please use the appropriate namespace where
# the infoscale pods are deployed in the namespace tag
#For eg: namespaces["infoscale-vtas"]
#Log the Request body of configmap changes in given namespace
- level: Request
resources:
- group: ""
resources: ["configmaps"]
namespaces: [""] #Fill namespace
#Log the Request of secrets changes in given namespace
- level: Request
resources:
- group: ""
resources: ["secrets"]
namespaces: [""] #Fill namespace
Login attempts to an OpenShift cluster get recorded in oauth-openshift- pod logs. The log level must be 'debug'. You can run oc edit authentications.operator.openshift.io to change the log level to 'debug'.
On an OpenShift cluster, pods creation and deletion gets logged in journalctl. Run journalctl no-pager on all the worker nodes for information about pods creation and deletion.
Related information