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.
  • 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.
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.
To enable extended logging for all core InfoScale components like VxVM, VxFS, and VCS, set the EO_COMPLIANCE to enabled.
Note: You must enableEO_COMPLIANCEfor your InfoScale deployment first. As a prerequisite, ensure that DNS is correctly configured or/etc/hostsis used to define IP address, full-qualified domain name(FQDN), and host name for the cluster node. Edit sds-operator deployment. Run the following commandoc/kubectl edit deployment -n infoscale-vtas \<deployment_name\>. Ensure that you updateEO_COMPLIANCEhere to enabled as under. name: EO_COMPLIANCE value: enabled After you edit and save the sds-operator deployment, the InfoScale sds operator restarts automatically. You have to manually restart infoscale-sds pods. Ensure that you restart one pod at a time. After a restarted pod is in a 'Ready' state, restart the next pod. 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
Related information