You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default Kratix creates a service account for use by pipelines. They are deterministically named (using the name of the Promise) and this allows for users to provide permissions to the pipelines using Kubernetes native options such as RBAC. There are two service accounts created per Promise. One for the promise workflows (both configure and delete) and one for the resource workflows (both configure and delete).
While the promise workflows always run in the kratix-platform-system namespace, the resource workflows run in the namespace where the request comes into. This is not always deterministic and therefore users right now need to manage copying any data (e.g. secrets or configmaps) and any permissions (e.g. rolebindings) over into each namespace a user might make a request from. This isn't a great experience.
We want permission to be something that is more native to the Promise writing experience and therefore can be created on request rather than separately managed. Some designs are being drawn up, if this is interesting please reach out!
Note: this is different from more control over permissions which will be handed in #193.
The text was updated successfully, but these errors were encountered:
By default Kratix creates a service account for use by pipelines. They are deterministically named (using the name of the Promise) and this allows for users to provide permissions to the pipelines using Kubernetes native options such as RBAC. There are two service accounts created per Promise. One for the promise workflows (both configure and delete) and one for the resource workflows (both configure and delete).
While the promise workflows always run in the
kratix-platform-system
namespace, the resource workflows run in the namespace where the request comes into. This is not always deterministic and therefore users right now need to manage copying any data (e.g. secrets or configmaps) and any permissions (e.g. rolebindings) over into each namespace a user might make a request from. This isn't a great experience.We want permission to be something that is more native to the Promise writing experience and therefore can be created on request rather than separately managed. Some designs are being drawn up, if this is interesting please reach out!
Note: this is different from more control over permissions which will be handed in #193.
The text was updated successfully, but these errors were encountered: