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
The Shipwright operator is granted RBAC permissions that are incredibly broad - it is effectively granted permission to be the "admin" over any workload and service account. This poses a security risk if the operator's service account token is leaked/exposed.
Snippet from kubectl describe clusterrole that is generated by OLM for the operator:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
events [] [] [create delete get list patch update watch]
limitranges [] [] [create delete get list patch update watch]
namespaces [] [] [create delete get list patch update watch]
services [] [] [create delete get list patch update watch]
validatingwebhookconfigurations.admissionregistration.k8s.io/v1beta1 [] [] [create delete get list patch update watch]
validatingwebhookconfigurations.admissionregistration.k8s.io [] [] [create delete get list patch update watch]
pods [] [] [get list watch create delete patch update]
secrets [] [] [get list watch create delete patch update]
configmaps [] [] [list get create update delete patch watch]
Expected Behavior
The operator's service account should adhere to the "principle of least privilege" - it should only be granted the minimal set of RBAC permissions to operate, and nothing more.
Some Kubernetes admission controllers (that are enabled by default in some distributions) can expand what is required for "least privilege":
OwnerReferencesEnforcement: controllers that set owner references on an object must have "delete" permission for said object.
Is there an existing issue for this?
Kubernetes Version
Kubernetes 1.24 or higher.
Shipwright Version
v0.12.0
Current Behavior
The Shipwright operator is granted RBAC permissions that are incredibly broad - it is effectively granted permission to be the "admin" over any workload and service account. This poses a security risk if the operator's service account token is leaked/exposed.
Snippet from
kubectl describe clusterrole
that is generated by OLM for the operator:Expected Behavior
The operator's service account should adhere to the "principle of least privilege" - it should only be granted the minimal set of RBAC permissions to operate, and nothing more.
Some Kubernetes admission controllers (that are enabled by default in some distributions) can expand what is required for "least privilege":
Steps To Reproduce
Anything else?
Introduced in 64baf78
The text was updated successfully, but these errors were encountered: