Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incomplete restrict secret access description #1307

Closed
joebowbeer opened this issue Feb 6, 2024 · 4 comments
Closed

Incomplete restrict secret access description #1307

joebowbeer opened this issue Feb 6, 2024 · 4 comments
Labels
bug Something isn't working stale All issues that are marked as stale due to inactivity

Comments

@joebowbeer
Copy link
Contributor

joebowbeer commented Feb 6, 2024

The existing documentation for restricting secret access is misleading, as it implies that access to secrets can be (completely) restricted by removing the secrets resource from one ClusterRole rule.

In addition to improving the documentation, it would be helpful if the docs explained how to update the role in order to completely restrict access.

I installed KEDA with access to secrets omitted as described in the docs:

https://keda.sh/docs/2.15/operate/cluster/#restrict-secret-access

but keda-operator still has "get" access to all secrets by way of a different rule in the keda-operator ClusterRole:

- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get

Discussion: kedacore/keda#4730

Related: kedacore/charts#605

Expected Behavior

kubectl auth can-i get secrets --as=system:serviceaccount:keda:keda-operator
no

Actual Behavior

kubectl auth can-i get secrets --as=system:serviceaccount:keda:keda-operator
yes

Steps to Reproduce the Problem

  1. Install KEDA
  2. Omit secrets as documented
  3. Run kubectl auth can-i get secrets

Specifications

  • KEDA Version: 2.13.0
@joebowbeer joebowbeer added the bug Something isn't working label Feb 6, 2024
@JorTurFer
Copy link
Member

Thanks for reporting,

- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get

This permission is required because KEDA can potentially work with any resource which implements /scale, so it needs that permission for working. The filter is done inside the code at some different levels:

To avoid the * , you can update that permission adding the other permissions required for your workloads, if you just use Deployments, replacing it with

- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get"]

Given that, I think that this can be a good improvement to docs, are you willing to open a PR clarifying it?

Copy link

stale bot commented Apr 10, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Apr 10, 2024
@zroubalik zroubalik removed the stale All issues that are marked as stale due to inactivity label Apr 10, 2024
Copy link

stale bot commented Jun 9, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Jun 9, 2024
Copy link

stale bot commented Jun 16, 2024

This issue has been automatically closed due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale All issues that are marked as stale due to inactivity
Projects
None yet
Development

No branches or pull requests

3 participants