EdgeConnect for Kubernetes Automation

Preview release

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.

Prerequisites

Role-based Access Control Setup for EdgeConnect

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:

  • Define a service account
  • Define permissions
  • Grant permissions to the service account

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.

Preview release

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.

Define service account

The EdgeConnect pods require a Kubernetes service account to authenticate to the Kubernetes API server.

  1. Create a ServiceAccount object with a definition similar to this example.

    # This is an example service account definition, adjust to your needs.
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: edgeconnect-deployment-rollout-restarter
      namespace: dynatrace

  2. Apply the ServiceAccount.

    kubectl apply -f edgeconnect-serviceaccount.yaml

Define Role/ClusterRole

To grant permissions to the ServiceAccount, you need to define a Role or ClusterRole.

  1. 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/v1
    kind: Role
    metadata:
      name: edgeconnect-deployment-rollout-restart
      namespace: myservice
    rules:
      - apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["get", "list", "patch"]

  2. Apply the Role.

    kubectl apply -f edgeconnect-role.yaml

We recommend applying the least privilege when defining the Role, adding only the necessary permissions.

Define RoleBinding/ClusterRoleBinding

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

  1. 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/v1
    kind: RoleBinding
    metadata:
      name: edgeconnect-deployment-rollout-restart
      namespace: myservice
    roleRef:
      kind: Role
      name: edgeconnect-deployment-rollout-restart
      apiGroup: rbac.authorization.k8s.io
    subjects:
    - kind: ServiceAccount
      name: edgeconnect-deployment-rollout-restarter
      namespace: dynatrace

  2. 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.
  • The namespace for Roles and RoleBindings can be, but does not need to be, the same namespace where EdgeConnect and ServiceAccounts are.

Use Cases

Below are two use cases that further clarify the usage of Role and ClusterRole definitions. You can find additional information on this topic here.

Managing Pods in a Namespace using 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/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, 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/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 cannot be accessed in other namespaces or cluster-wide resources such as nodes.

Viewing Nodes Across the Cluster using ClusterRole and ClusterRoleBinding

Security

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/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- 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/v1
kind: ClusterRoleBinding
metadata:
  name: bind-node-viewer
subjects:
- kind: User
  name: your-username
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: ""

Deploy EdgeConnect in Kubernetes

There are two approaches for deploying EdgeConnect in your Kubernetes cluster

Follow one of the approaches to deploy EdgeConnect.