feat: support BoundServiceAccountToken triggerAuth provider

[maxcao13]

Updates CRDs to support BoundServiceAccountToken trigger auth provider/source. Also adds a helm value of type array called serviceAccountTokenCreationRoles which allows you to add objects of name and namespace corresponding to service accounts in the cluster that you'd like the keda-operator to be able to request service account tokens from.

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• README is updated with new configuration values (if applicable) learn more
• A PR is opened to update KEDA core (repo) (if applicable, ie. when deployment manifests are modified)

Related to kedacore/keda#6272

[JorTurFer]

As default, KEDA doesn't have permission in the RBAC to create these tokens (and not granting it as default is worth IMHO), but maybe we could add an option to include the required permissions if users enable them (requiring explicit activation to include the required extra RBAC)

[maxcao13]

Added a helm value of serviceAccountTokenCreationRoles which allows you to add objects of name and namespace corresponding to service accounts in the cluster that you'd like the keda-operator to be able to request service account tokens from. This is in: bac167e

I'm sort of new to writing helm charts, so please let me know if a restructure or renaming is needed here.

[maxcao13]

If people want to test this, I created this yaml file and applied it to my kind cluster (it pretty much follows the bound-service-account-e2e test I wrote in the main repo).

If you don't want to do all that, you can just add an item to the serviceAccountTokenCreationRoles with some namespaced name of a valid service account, and then install the chart and just check that the auth works:

# values.yaml
permissions:
  operator:
    restrict:
      serviceAccountTokenCreationRoles:
      - name: mysa
        namespace: default

$ kubectl create sa mysa -n default
serviceaccount/mysa created
$ kubectl auth can-i create serviceaccount/mysa --subresource=token --as system:serviceaccount:keda:keda-operator -n default
yes

If you want to test the bound service account token feature as a whole with helm:

1. First I installed the helm chart with helm install keda-bsat ./keda/ -n keda --create-namespace
2. Then I apply this large manifest, which sets up all the logic needed for the test deployment to scale in and out.

apiVersion: v1
kind: Namespace
metadata:
  name: myproject
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysa
  namespace: myproject
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: bound-trigger
  namespace: myproject
spec:
  boundServiceAccountToken:
    - parameter: token
      serviceAccountName: mysa
---
### metrics api-like scale resource
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bound-metrics-server
  namespace: myproject
  labels:
    app: bound-metrics-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bound-metrics-server
  template:
    metadata:
      labels:
        app: bound-metrics-server
    spec:
      containers:
      - name: metrics
        image: ghcr.io/kedacore/tests-bound-service-account-token:latest
        ports:
        - containerPort: 8080
        imagePullPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: bound-metrics-server
  namespace: myproject
spec:
  selector:
    app: bound-metrics-server
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: myboundscaledobject
  namespace: myproject
  labels:
    app: bound-mydeploy
spec:
  scaleTargetRef:
    name: bound-mydeploy
  minReplicaCount: 3
  maxReplicaCount: 20
  cooldownPeriod:  1
  fallback:
    failureThreshold: 3
    replicas: 0
  triggers:
  - type: metrics-api
    metadata:
      targetValue: "5"
      activationTargetValue: "20"
      url: "http://bound-metrics-server.myproject.svc.cluster.local:8080/api/value"
      valueLocation: 'value'
      authMode: "bearer"
    authenticationRef:
      name: bound-trigger
---
### deployment we are scaling
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: bound-mydeploy
  name: bound-mydeploy
  namespace: myproject
spec:
  selector:
    matchLabels:
      app: bound-mydeploy
  replicas: 0
  template:
    metadata:
      labels:
        app: bound-mydeploy
    spec:
      containers:
      - name: nginx
        image: nginxinc/nginx-unprivileged
---
### Note that these are the rbacs required for the mysa service account to authenticate with the bound-metrics-server container api
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: bound-metrics-server
rules:
- nonResourceURLs:
  - /api/value
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bound-metrics-server
subjects:
- kind: ServiceAccount
  name: mysa
  namespace: myproject
roleRef:
  kind: ClusterRole
  name: bound-metrics-server
  apiGroup: rbac.authorization.k8s.io
---
### This is the rbac required for the metrics-deployment to be able to request token reviews and subject access reviews
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: token-review-and-subject-access-review-role
rules:
- apiGroups:
  - "authentication.k8s.io"
  resources:
  - tokenreviews
  verbs:
  - create
- apiGroups:
  - authorization.k8s.io
  resources:
  - subjectaccessreviews
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: token-review-and-subject-access-review-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: token-review-and-subject-access-review-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: myproject

4. And then I specified in the serviceAccountTokenCreationRoles in values.yaml to be

# values.yaml
permissions:
  operator:
    restrict:
      serviceAccountTokenCreationRoles:
      - name: mysa
        namespace: myproject

and upgraded the chart.

5. Then finally you can check the deployment is scaled to the minReplicas:

$ oc get deploy -n myproject
NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
bound-metrics-server   1/1     1            1           55m
bound-mydeploy         3/3     3            3           55m

Note that, I also had to change the helm keda images to point to quay.io/macao/keda since the feature is not live yet.

[JorTurFer]

Nice change to limit the scope of the permission, thanks a lot for the effort!
The only additions that I'd add are:

• The option to not set the service account name and just the namespace, in case of cluster admins want to allow to assume tokens of any SA in a given namespace
• another field to enable the permission at cluster level if users explicitly set it as desired (for example, allowAllServiceAccountTokenCreation to register a cluster role instead of role by role)

Said this, the current approach is nice and we can update it in future PRs if there is demand for these things