Create a Kubernetes ClusterRole with permissions that allow access to Kubernetes cluster resources like Pods and ConfigMaps. You can also create a combination of a ClusterRole and Role to further restrict Informatica's permissions in your Kubernetes cluster.
Configure permissions for the Kubernetes ClusterRole to create and manage resources in the Kubernetes cluster.
The following table describes each resource that the ClusterRole needs to access:
Resource
Description
Services
Used to communicate across Kubernetes Pods.
Pods
Used to run Spark drivers and Spark executors.
Secrets
Used to pass sensitive metadata to Kubernetes Pods.
Configmaps
Used to pass Spark configurations to Kubernetes Pods.
DaemonSets
Used to deploy the Spark shuffle service.
Deployments
Used to deploy a keystore on the cluster so that Kubernetes Pods can use keys to access the Secure Agent.
The permissions required depend on whether the cluster runs mappings with the Spark shuffle service. The Spark shuffle service helps the cluster perform dynamic allocation for Spark jobs. The service is responsible for persisting shuffle files beyond the lifetime of the executors, allowing the number of executors to scale up and down without losing computation.
A ClusterRole is global and not associated with a namespace. If you need to restrict permissions to a specific namespace, you can split the ClusterRole permissions into two different roles.
Minimum permissions to run a mapping with the Spark shuffle service
The following code snippet shows the minimum permissions required to run a mapping with the Spark shuffle service:
The permissions in this code snippet applies to all namespaces.
If you need to limit the permissions to certain namespaces only, split these permissions into two roles: Role and ClusterRole. ClusterRole contains permissions for resources that are global, while Role contains permissions for resources that are specific to a namespace.
The following code snippet shows the permissions for Role:
The permissions in this code snippet applies to all namespaces.
If you need to limit the permissions to certain namespaces only, split these permissions into two roles: Role and ClusterRole. ClusterRole contains permissions for resources that are global, while Role contains permissions for resources that are specific to a namespace.
The following code snippet shows the permissions for Role:
Optionally, you can enable job priority to allow the cluster role to schedule jobs on the self-service cluster according to the job priority that a developer sets for a mapping task in Data Integration.
To enable job priority, complete the following tasks:
1Grant the following permissions to the cluster role:
2Set the following custom property in the advanced configuration:
ccs.enable.app.priority=true
Create role bindings
To grant the permissions defined in the roles, create a role binding between the cloud user and the Kubernetes ClusterRole and Role.
For example, you can create a service account in an Informatica-specific namespace and add the service account token to the kubeconfig file. Then, create role bindings between the service account and the roles.
Note: If you use a service account, open the Runtime Configuration tab of the advanced configuration and set the property infa.k8s.spark.custom.service.account.name to the service account name.
For more information, refer to the your cloud provider's documentation.
Use an Informatica-managed service account (alternative)
If you don't provide the service account name using the property infa.k8s.spark.custom.service.account.name, Informatica creates a default service account, cluster role, and cluster role binding.
Informatica creates a service account called infa-spark and a cluster role binding called infa-spark-role for the Spark driver. This cluster role binding uses the default cluster role edit that's available in Kubernetes clusters. The edit role lets you perform basic actions like deploying Pods. For more information about the edit role, see Kubernetes documentation.
When the Spark shuffle service is enabled, Informatica creates a separate service account, cluster role, and cluster role binding on the cluster. Informatica assigns the following cluster role permissions to the service account: