feat: update CRDs for 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]>
The array allows users to supply KEDA with the names and namespaces of service accounts that they would like the keda-operator to request tokens from. These service account tokens are then used in turn for the boundServiceAccountToken trigger source 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?
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