Service Account Privileges

A Service Account is an identity used by processes in a pod to control permissions and access levels. If you are not authorized to create a Service Account during the installation of the Helm chart for Agent deployment, you can use your own Service Account.

To use your own service account, you must do the following:

• Prepare a Service Account and assign required privileges to run Kubernetes jobs, as described in Granting Authorizations to Run Kubernetes Jobs.
• (OpenShift) Grant the Service Account use of an appropriate security context constraint (SCC), as described in Agent Runtime Privileges on OpenShift.

Granting Authorizations to Run Kubernetes Jobs

This procedure describes how to prepare a Service Account and assign required privileges to run Kubernetes jobs.

Begin

1. Contact your Kubernetes cluster administrator to allocate a Service Account for the Control-M/Agent. 

2. Define a role for your Kubernetes jobs, as follows:

   # Sample Role for running Kubernetes jobs
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
    name: job-executor
   rules:
   - apiGroups:
    - batch
    resources:
    - jobs
    - jobs/status
    verbs:
    - create
    - get
    - list
    - delete
   - apiGroups:
    - ""
    resources:
    - pods
    - pods/log
    verbs:
    - get
    - list

3. Grant the role that you defined in the previous step to the Agent pod Service Account by defining a Role Binding, as follows: 

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: controlm-agent-job-privileges
    namespace: namespace_where_jobs_run
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: job-executor
   subjects:
   - kind: ServiceAccount
     name: controlm-agent-pod-serviceaccount
    namespace: namespace_where_agent_is_running

   Where the following variables must be replaced with values that are relevant for your environment:

   • namespace_where_jobs_run
   • controlm-agent-pod-serviceaccount: The same name that you define in the pod.serviceAccount.name parameter during installation of the Helm chart, or the default ".Release.Name.-sa"
   • namespace_where_agent_is_running

4. If you want to run jobs in other namespaces, perform this procedure in each namespace.

   For a diagram that demonstrates multiple namespaces in the Kubernetes cluster, see Control-M-for-Kubernetes-Overview.

Agent Runtime Privileges on OpenShift

By default, the Agent processes in the container run as a specific user named controlm with UID=1000. In OpenShift this requires elevated privileges to run the pod, which is enabled using an appropriate security context constraint (SCC). During Helm chart installation, the Agent is deployed, by default, with permission to use the nonroot-v2 SCC.

If you create your own service account, you must grant the service account use of an appropriate SCC. The recommended SCC is nonroot-v2. However, if your IT environment or corporate security policies do not allow you to deploy a privileged pod, use the pod.securityContext parameter during Helm chart installation and set it to auto to disable the use of the nonroot-v2 SCC and to instead use the cluster default SCC (typically, the restricted-v2 SCC).