Using kubernetes rbac.authorization.k8s.io with keda.sh

Question

Pulumi · Accepted Answer

Kubernetes Role-Based Access Control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an organization. RBAC for Kubernetes can be managed using Pulumi's Kubernetes Provider, which allows you to declare Kubernetes resources in code and manage them programmatically.

KEDA, Kubernetes-based Event-Driven Autoscaling, is a component that allows Kubernetes to autoscale applications, including scaling to and from zero, based on event metrics from a variety of sources.

To provide the necessary RBAC permissions for KEDA on a Kubernetes cluster, the following steps are typically needed:

1. Create a `ServiceAccount` for KEDA to operate under.
2. Create a `Role` or `ClusterRole` that defines the required permissions. The choice between `Role` and `ClusterRole` depends on whether you need namespace-scoped or cluster-wide access.
3. Create a `RoleBinding` or `ClusterRoleBinding` that ties the `Role` or `ClusterRole` to the `ServiceAccount`.

Here's a program written in TypeScript that creates these resources using Pulumi's Kubernetes Provider:

```typescript
import * as k8s from "@pulumi/kubernetes";

// Create a ServiceAccount for KEDA
const kedaServiceAccount = new k8s.core.v1.ServiceAccount("kedaServiceAccount", {
    metadata: {
        name: "keda-service-account",
        namespace: "keda" // Make sure this namespace exists or is created beforehand.
    }
});

// Create a ClusterRole for KEDA
const kedaClusterRole = new k8s.rbac.v1.ClusterRole("kedaClusterRole", {
    metadata: {
        name: "keda-cluster-role"
    },
    rules: [
        {
            apiGroups: [""],
            resources: ["pods", "services"],
            verbs: ["get", "list", "watch"]
        },
        {
            apiGroups: ["extensions", "apps"],
            resources: ["deployments", "replicasets"],
            verbs: ["get", "list", "watch"]
        },
        // Add more rules here based on the exact resources KEDA needs to interact with.
    ]
});

// Create a ClusterRoleBinding to bind the ServiceAccount to the ClusterRole
const kedaClusterRoleBinding = new k8s.rbac.v1.ClusterRoleBinding("kedaClusterRoleBinding", {
    metadata: {
        name: "keda-cluster-role-binding"
    },
    subjects: [{
        kind: "ServiceAccount",
        name: kedaServiceAccount.metadata.name,
        namespace: "keda"
    }],
    roleRef: {
        kind: "ClusterRole",
        name: kedaClusterRole.metadata.name,
        apiGroup: "rbac.authorization.k8s.io",
    }
});

// Exporting the service account name for reference
export const serviceAccountName = kedaServiceAccount.metadata.name;
```

Explanation of the resources created:

- **ServiceAccount (`kedaServiceAccount`)**: This is a Kubernetes service account under which KEDA will run. Service accounts provide an identity for processes that run in a Pod.

- **ClusterRole (`kedaClusterRole`)**: This defines a set of permissions that can be assigned to resources within the entire cluster. In this code snippet, we have basic permissions to get, list, and watch "pods", "services", "deployments", and "replicasets". You'll need to adjust the resources and verbs according to what KEDA needs to access.

- **ClusterRoleBinding (`kedaClusterRoleBinding`)**: This binds the `ClusterRole` created above to the `ServiceAccount`. This means any pod running with the `kedaServiceAccount` will have the permissions defined in `kedaClusterRole`.

Remember to adjust the namespace to match where you want to deploy KEDA, and ensure you create any custom rules tailored to the needs of your specific KEDA deployment.

After creating these resources, the KEDA controller should have the necessary permissions to monitor and scale the applications based on defined event sources.