Security best practices for Kubernetes Automation

• Latest Dynatrace
• Troubleshooting
• 2-min read
• Published Apr 24, 2025

Kubernetes is a powerful tool; ensure you use it securely by following our recommendations.

Define minimal privilege

Define the minimum set of privileges for Workflows by granting only those privileges and permissions to the workflow used to manage Kubernetes resources only the minimum permissions needed. For more information on Workflows permissions, see Set up Kubernetes Connector.

Change ownership of a private workflow to group ownership

Change ownership of a workflow from an individual user to a group if you want more people to access the workflow. You can change the ownership of a workflow using Ownership. By changing the ownership of a workflow to a group, all group members can access the workflow, depending on their permissions.

For more information on the owner concept of a workflow, see User permissions for workflows.

Deploy separate EdgeConnects for different use cases

Deploy different EdgeConnects for different use cases.

Imagine that different teams are responsible for managing different parts of Kubernetes. If you create a dedicated EdgeConnect for each team, you can use Kubernetes Role-based access control to grant each team the minimum permissions required to achieve their use case.

Set up sufficient permissions for Role and ClusterRole

Ensure the Role/ClusterRole permissions are sufficient for your workflow tasks. Whether you create a Role or ClusterRole depends on which resources you're trying to access. For instance, you would create a Role if you need to manage resources within a specific namespace. However, if you need to manage resources across the entire cluster, you would make a ClusterRole.

If resources inside the namespace my-service should be accessed by the Kubernetes Automation workflow actions, a RoleBinding for the created role must exist in the namespace my-service. Meanwhile, the ServiceAccount and EdgeConnect deployments can be placed in a different namespace, such as dynatrace.

To grant the permissions defined in the Role/ClusterRole to the ServiceAccount, you need to specify a RoleBinding/ClusterRoleBinding.

Use Cases

Here are two examples of how you can use Role/ClusterRole definitions together with RoleBinding/ClusterRoleBinding.

Manage pods in a namespace using Role and RoleBinding

To create a role that allows pods to be managed in the myservice namespace, use the following configuration:

# This is a role definition for this specific example. Adjust it to your needs.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: myservice
  name: pod-manager
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch", "create", "delete"]

To bind this role to a user, use the following configuration:

# This is a role-binding definition for this specific example. Adjust it to your needs.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-pod-manager
  namespace: myservice
subjects:
- kind: User
  name: your-username
  apiGroup: ""
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: ""

With this configuration, the role is limited to this specific namespace, and the pods can't be accessed in other namespaces or cluster-wide resources such as nodes.

View nodes across the cluster using ClusterRole and ClusterRoleBinding

To create a cluster role that allows viewing a cluster-wide resource, nodes in this example, across the entire cluster, use the following configuration:

# This is a cluster-role definition for this specific example. Adjust it to your needs.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

To bind this cluster role to a user, use the following configuration:

# This is a cluster-role binding definition for this specific example. Adjust it to your needs.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind-node-viewer
subjects:
- kind: User
  name: your-username
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: ""