feat: support BoundServiceAccountToken triggerAuth provider
#701
Conversation
maxcao13
force-pushed
the
bound-service-account-token
branch
from
9a06a5d to
923b1d2
Compare
There was a problem hiding this comment.
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)
Signed-off-by: Max Cao <[email protected]>
maxcao13
force-pushed
the
bound-service-account-token
branch
from
923b1d2 to
bac167e
Compare
|
Added a helm value of I'm sort of new to writing helm charts, so please let me know if a restructure or renaming is needed here. |
| @@ -146,4 +146,51 @@ subjects: | |||
| - kind: ServiceAccount | |||
| name: {{ (.Values.serviceAccount.operator).name | default .Values.serviceAccount.name }} | |||
| namespace: {{ .Release.Namespace }} | |||
| {{- if .Values.serviceAccountTokenCreationRoles }} | |||
There was a problem hiding this comment.
I am not sure minimal-rbac.yaml is the correct place for this
@jkremser could you please suggest the best approach here?
There was a problem hiding this comment.
@zroubalik @wozniakjan Based off the KEDA meeting on Feb 11, I used #728 as a reference, but IDK if that was the intended direction for this PR (since I wasn't present). I also don't want to take credit for this change so if we are fine with this, maybe we can just merge that PR first.
Signed-off-by: Max Cao <[email protected]>
maxcao13
force-pushed
the
bound-service-account-token
branch
from
bac167e to
3fe5b3c
Compare
maxcao13
changed the title
BoundServiceAccountToken triggerAuth providerBoundServiceAccountToken triggerAuth provider
| @@ -140,6 +140,7 @@ their default values. | |||
| | `operator.replicaCount` | int | `1` | Capability to configure the number of replicas for KEDA operator. While you can run more replicas of our operator, only one operator instance will be the leader and serving traffic. You can run multiple replicas, but they will not improve the performance of KEDA, it could only reduce downtime during a failover. Learn more in [our documentation](https://keda.sh/docs/latest/operate/cluster/#high-availability). | | |||
| | `operator.revisionHistoryLimit` | int | `10` | ReplicaSets for this Deployment you want to retain (Default: 10) | | |||
| | `permissions.operator.restrict.namesAllowList` | list | `[]` | Array of strings denoting what secrets the KEDA operator will be able to read, this takes into account also the configured `watchNamespace`. the default is an empty array -> no restriction on the secret name | | |||
| | `permissions.operator.restrict.saTokens` | bool | `true` | Restrict Service Account Token Creation Access for KEDA operator | | |||
There was a problem hiding this comment.
I liked the previous approach, creating a RBAC permission service account by service account within a range. Just using a flag is quite open taking into account that these permissions allow to act in behalf of other service accounts, escalating privileges in the cluster. Using the range is aligned with the approach that we took for custom resources, where you can specify them one by one if you want (being more restrictive in this case and requiring to grant one by one)
Personally I prefer the range approach, but maybe @zroubalik or @wozniakjan have other opinion here
Updates CRDs to support
BoundServiceAccountTokentrigger auth provider/source. Also adds a helm value of type array calledserviceAccountTokenCreationRoleswhich allows you to add objects ofnameandnamespacecorresponding to service accounts in the cluster that you'd like thekeda-operatorto be able to request service account tokens from.Checklist
Related to kedacore/keda#6272