Documentation: RBAC Documentation should be clearer about deny actions

[jdfalk]

Checklist:

• [X] I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• [X] I've included steps to reproduce the bug.
• [X] I've pasted the output of argocd version. ^ NA as this is a documentation bug

Describe the bug

The current RBAC documentation does not clearly state if a deny rule overrides a allow rule. For instance, if I have this RBAC policy, does the allow or the deny take precedence?

        p, role:qa, projects, get, *, allow
        p, role:qa, projects, get, production, deny

In addition, does order matter?

        p, role:qa, projects, get, production, deny
        p, role:qa, projects, get, *, allow

None of that is well documented in the RBAC documentation. Something I think would be a critical area for several organizations.

To Reproduce Read https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/rbac.md

Expected behavior

A clear and concise description of what should happen in these situations, and additional examples.

[pavanfhw]

Can someone with knowledge or a successful experience comment on this? In my case for example I can't deny get access to apps/projects in a role. The user with the role can see all apps and projects.

[doctornkz]

We are having the same issue and even worse - our SSO applies too many groups to user automatically, so it's very impossible to implement deny mechanic there - default access will be leaked again with every new group. Could someone fix that IRL ?

[iamcryptoki]

@pavanfhw We had the same issue but figured it out. You have to disable default policy by setting policy.default with the role role: ''.

The configuration below does not work:

policy.default: role:readonly
policy.csv: |
  p, role:developers, applications, *, */*, allow
  p, role:developers, applications, *, production/*, deny

Users with the role developers can still view applications in the production project.

The configuration below works:

policy.default: role:''
policy.csv: |
  p, role:developers, applications, *, */*, allow
  p, role:developers, applications, *, production/*, deny

Users with the role developers can no longer see applications in the production project.

[crenshaw-dev]

Hopefully this helps a bit with the policy.default behavior: https://github.com/argoproj/argo-cd/pull/10896

But yeah, we need more general commentary about how deny works.

[akorp]

Thanks for the info on the behaviour of policy.default!

There are still some missing bits in docs on precedence of allow and deny policies. If I have two polices for the same resource, one allowing and another denying, which will take precedence and in when? Looks like a resource-specific policy for a resource take precedence over * policy and in two policies with a similar scope over a resource, deny take precedence over allow. But this is not documented and users have to use try-and-fail method. Documentation does not even mention that deny option is available.

[prashant0085]

I am also working on setting policies and not sure how the precedence will work below scenario.

I want to restrict a role to perform update and delete for 1 specific apps and then allow all actions for all other apps and I came up with below and not sure what what will get applied without actually applying.

p, role:role-1, applications, update, default/app-1, deny
p, role:role-1, applications, delete, default/app-1, deny
p, role:role-1, applications, *, default/*, allow

[agaudreault]

Closed by https://github.com/argoproj/argo-cd/pull/18124