Kubernetes Automation is currently in Preview release and only accessible to selected customers. If you would like to share feedback or ideas, join the preview by signing up via this form or contacting your Customer Success Manager.
For more information, see
After you join the preview program for Kubernetes Automation, we'll provide Hub subscription details. With those subscription details, you can activate the capability by following these steps.
This guide provides detailed steps for provisioning EdgeConnect for Kubernetes Automation. After executing the steps, you have deployed permissions in your Kubernetes cluster. This is done in preparation for EdgeConnect so it can, once deployed, route the API requests executed by the Kubernetes workflow actions to the Kubernetes API.
All requests from the Kubernetes Automation workflow actions are sent via EdgeConnect to the Kubernetes API server. You can use Kubernetes Role-based access control (RBAC) to control what actions are allowed in the workflow.
This guide walks you through a setup that allows listing pods in your workflow:
Ensure that the Role
/ClusterRole
permissions are sufficient for your workflow tasks. Whether you create a Role
or ClusterRole
depends on which resources you are trying to access. For instance, if you need to manage resources within a specific namespace, you would create a Role
. However, if you need to manage resources across the entire cluster, you would create a ClusterRole
.
We recommend using the Role
for all Kubernetes Automation workflow actions.
If you need access to the whole cluster, you can use the ClusterRole
.
If you use theClusterRole
, consider the security implications the ClusterRole
carries.
Review the Security Best practices, such as the principle of least privilege.
For this, the Role
must provide permissions to make those API calls, and a RoleBinding
or a ClusterRoleBinding
must exist for the targeted namespace.
For example, 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
.
The EdgeConnect pods require a Kubernetes service account to authenticate to the Kubernetes API server.
Create a ServiceAccount
object with a definition similar to this example.
# This is an example service account definition, adjust to your needs.apiVersion: v1kind: ServiceAccountmetadata:name: edgeconnect-deployment-rollout-restarternamespace: dynatrace
Apply the ServiceAccount
.
kubectl apply -f edgeconnect-serviceaccount.yaml
To grant permissions to the ServiceAccount
, you need to define a Role
or ClusterRole
.
Create a Role
or a ClusterRole
. For example, if you would like to implement the use case for restarting a deployment in a workflow, the Role
needs the following permissions.
# This is an example role definition, adjust to your needs.apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:name: edgeconnect-deployment-rollout-restartnamespace: myservicerules:- apiGroups: ["apps"]resources: ["deployments"]verbs: ["get", "list", "patch"]
Apply the Role
.
kubectl apply -f edgeconnect-role.yaml
We recommend applying the least privilege when defining the Role
, adding only the necessary permissions.
To grant the permissions defined in the Role
/ClusterRole
to the ServiceAccount
, you need to specify a RoleBinding
/ClusterRoleBinding
.
Create a RoleBinding
or ClusterRoleBinding
. For example, if you want to grant permission to the previously defined Role
to the ServiceAccount
, specify a RoleBinding
similar to this.
# This is an example role binding definition, adjust to your needs.apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: edgeconnect-deployment-rollout-restartnamespace: myserviceroleRef:kind: Rolename: edgeconnect-deployment-rollout-restartapiGroup: rbac.authorization.k8s.iosubjects:- kind: ServiceAccountname: edgeconnect-deployment-rollout-restarternamespace: dynatrace
Apply the RoleBinding
.
kubectl apply -f edgeconnect-rolebinding.yaml
Roles
and RoleBindings
must be in the same namespace.EdgeConnect
and ServiceAccounts
must be in the same namespace.Roles
and RoleBindings
can be, but does not need to be, the same namespace where EdgeConnect
and ServiceAccounts
are.Below are two use cases that further clarify the usage of Role
and ClusterRole
definitions.
You can find additional information on this topic here.
Role
and RoleBinding
To create a role that allows pods to be managed in the myservice
namespace, you would use the following configuration:
# This is a role definition for this specific example, adjust to your needs.apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:namespace: myservicename: pod-managerrules:- apiGroups: [""]resources: ["pods"]verbs: ["get", "list", "watch", "create", "delete"]
To bind this role to a user, you would use the following configuration:
# This is a role binding definition for this specific example, adjust to your needs.apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:name: bind-pod-managernamespace: myservicesubjects:- kind: Username: your-usernameapiGroup: ""roleRef:kind: Rolename: pod-managerapiGroup: ""
With this configuration, the role is limited to this specific namespace, and the pods cannot be accessed in other namespaces or cluster-wide resources such as nodes.
ClusterRole
and ClusterRoleBinding
Use the ClusterRole
carefully, and only if it is required.
Review the Security Best practices and adhere to the principle of least privilege.
To create a cluster role that allows viewing a cluster-wide resource, nodes in this example, across the entire cluster, you would use the following configuration:
# This is a cluster-role definition for this specific example, adjust to your needs.apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:name: node-viewerrules:- apiGroups: [""]resources: ["nodes"]verbs: ["get", "list", "watch"]
To bind this cluster role to a user, you would use the following configuration:
# This is a cluster-role binding definition for this specific example, adjust to your needs.apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:name: bind-node-viewersubjects:- kind: Username: your-usernameapiGroup: ""roleRef:kind: ClusterRolename: node-viewerapiGroup: ""
There are two approaches for deploying EdgeConnect in your Kubernetes cluster
Follow one of the approaches to deploy EdgeConnect.