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
Using the permissions at this level for ease of engineering release is not in alignment with least permissions, which we should expect from a security tool with global visibility.
Customers should not need to grant "get, watch" permissions for allApiGroups and Resources for one resource that uses the Get verb and none which are reported to use the Watch verb. Future functionality is not a reason for over-provisioning of permissions. (Something that the Wiz platform would flag in other portions of cloud infrastructure.)
In the event of malicious access/poisioning of the Wiz connector - this reduced scope should limit the damage possible.
The text was updated successfully, but these errors were encountered:
Per documentation and FAQ - https://docs.wiz.io/wiz-docs/docs/kubernetes-req-perm-api?lng=en
Required permissions are much more limited in scope than the used definition:
https://github.com/wiz-sec/charts/blob/master/wiz-kubernetes-connector/templates/service-account-cluster-reader.yaml#L39
Using the permissions at this level for ease of engineering release is not in alignment with least permissions, which we should expect from a security tool with global visibility.
Customers should not need to grant "get, watch" permissions for all
ApiGroups
andResources
for one resource that uses theGet
verb and none which are reported to use theWatch
verb. Future functionality is not a reason for over-provisioning of permissions. (Something that the Wiz platform would flag in other portions of cloud infrastructure.)In the event of malicious access/poisioning of the Wiz connector - this reduced scope should limit the damage possible.
The text was updated successfully, but these errors were encountered: