Enabling cross-namespace authentication for KEDA scalers

Question

Pulumi · Accepted Answer

Enabling cross-namespace authentication for Kubernetes Event-Driven Autoscaling (KEDA) scalers involves configuring Role-based Access Control (RBAC) to grant a service account in one namespace the necessary permissions to access resources in another namespace. KEDA scalers can then use this configured service account to authenticate and scale applications based on metrics from resources in a different namespace.

To facilitate cross-namespace authentication for a KEDA scaler, you need to perform the following steps:

1. Create a ServiceAccount in the namespace where your KEDA scaler will be deployed.
2. Set up a Role with permissions to access the resources in the target namespace.
3. Create a RoleBinding to associate the Role with the ServiceAccount in the scaler's namespace.
4. Configure your KEDA scaler to use the created ServiceAccount.

The following Pulumi program written in TypeScript demonstrates how to set up cross-namespace authentication for KEDA scalers using Pulumi's Kubernetes provider:

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

const scalerNamespace = "keda-scaler-ns";
const targetNamespace = "target-ns";

// Step 1: Create a ServiceAccount in the namespace for KEDA scalers.
const kedaServiceAccount = new k8s.core.v1.ServiceAccount("keda-service-account", {
    metadata: {
        namespace: scalerNamespace,
    },
});

// Step 2: Set up a Role in the target namespace with the required permissions.
const targetNamespaceRole = new k8s.rbac.v1.Role("target-namespace-role", {
    metadata: {
        namespace: targetNamespace,
    },
    rules: [
      // Add the necessary RBAC rules for the resources your KEDA scaler needs to access.
      // This is an example that allows reading Secrets in the target namespace.
      {
          apiGroups: [""],
          resources: ["secrets"],
          verbs: ["get", "list", "watch"],
      },
    ],
});

// Step 3: Create a RoleBinding in the target namespace.
// This binds the Role to the ServiceAccount in the scaler's namespace.
const roleBinding = new k8s.rbac.v1.RoleBinding("keda-role-binding", {
    metadata: {
        namespace: targetNamespace,
    },
    subjects: [{
        kind: "ServiceAccount",
        name: kedaServiceAccount.metadata.name,
        namespace: scalerNamespace,
    }],
    roleRef: {
        kind: "Role",
        name: targetNamespaceRole.metadata.name,
        apiGroup: "rbac.authorization.k8s.io",
    },
});

// Step 4 would be to configure your KEDA scaler to use the created ServiceAccount.
// This typically involves setting the serviceAccountName in your KEDA ScaledObject configuration.

// Export the ServiceAccount name that KEDA will use in the scaler's namespace
export const kedaScalerServiceAccountName = kedaServiceAccount.metadata.name;

// Use the created ServiceAccount in your KEDA ScaledObject configuration.
```

This program creates the necessary Kubernetes resources for enabling cross-namespace authentication:

- A `ServiceAccount` named `"keda-service-account"` is created in the namespace where the KEDA scaler will be deployed (`scalerNamespace`).

- A `Role` named `"target-namespace-role"` is created in the `targetNamespace`. This `Role` specifies the permissions needed to access certain resources (like Secrets in this example).

- A `RoleBinding` named `"keda-role-binding"` is created in the `targetNamespace`. It binds the `ServiceAccount` from `scalerNamespace` to the `Role` in `targetNamespace`. This allows the KEDA scaler to authenticate using the `ServiceAccount` across namespaces and access the specified resources.

Remember to replace the `rules` array in the `Role` resource with the appropriate permissions that your scaler needs to access in the `targetNamespace`.

Finally, you would configure your KEDA `ScaledObject` to use the `ServiceAccount` by specifying its name in the `serviceAccountName` field inside your KEDA scaler's deployment manifest.

Keep in mind that cross-namespace access can pose security risks if not managed carefully, so ensure that you only grant the minimum required permissions to the scaler's `ServiceAccount`.