RBAC: inconsistent and unclear behavior

[Gianluca755]

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.

Describe the bug There are two things:

1. A user logging in with OIDC SSO with misconfigured RBAC roles' association receives permissions.
2. A local user logging in with password doesn't need the RBAC roles' association.

To Reproduce The OIDC is with Microsoft Azure and without DEX.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argo-cd
data:
  accounts.local-user: login
  admin.enabled: "false"
  exec.enabled: "true"
  server.rbac.log.enforce.enable: "true"
  oidc.config: |
    name: AzureAD
    issuer: https://login.microsoftonline.com/...
    clientID: ...
    clientSecret: $argo-cd-sso-azure-ad:clientSecret
    requestedIDTokenClaims:
      roles:
        essential: true
    requestedScopes: [ "openid", "profile", "email" ]

1) Login with SSO

With this confimap the user can see the apps

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    g, sandbox-sso, aaa
    p, sandbox-sso, applications, get, */*, allow
  policy.default: ""
  scopes: '[roles]'

With this configmap the user cannot see the apps

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    p, sandbox-sso, applications, get, */*, allow
  policy.default: ""
  scopes: '[roles]'

2) Login with local user

With this configmap the user can see the apps

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    g, local-user, aaa
    p, local-user, applications, get, */*, allow
  policy.default: ""
  scopes: '[roles]'

With this configmap the user can see the apps

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    p, local-user, applications, get, */*, allow
  policy.default: ""
  scopes: '[roles]'

Expected behavior I'm not sure about the correct behavior.

1. A wrong mapping should not give permissions.
2. If the mapping g, abc, xyz is not needed in case of local users it should be better specified.

Version

    "Version": "v2.7.4+a33baa3.dirty",
    "BuildDate": "2023-06-05T19:00:34Z",
    "GitCommit": "a33baa301fe61b899dc8bbad9e554efbc77e0991",
    "GitTreeState": "dirty",
    "GoVersion": "go1.19.6",
    "Compiler": "gc",
    "Platform": "linux/amd64",
    "KustomizeVersion": "v5.0.1 2023-03-14T01:32:48Z",
    "HelmVersion": "v3.11.2+g912ebc1",
    "KubectlVersion": "v0.24.2",
    "JsonnetVersion": "v0.19.1"

[ev1lm0nk3y]

RBAC can be confusing in ArgoCD, I'm trying to update some of the docs to be more clear about what's needed and what isn't.

I think I know the answer: A locally defined user doesn't need to be assigned to a "group" to get permissions but an SSO provided "role" (could be any other field) needs to map to an ArgoCD "group" that then has permissions.

In your SSO example, there is only a "person" defined, but no mapping between the logged in user and that Argo role. There's a page that actually shows what argo groups you are a member of after logging in that can help demonstrate the differences.

[Gianluca755]

Hello ev1lm0nk3y, for the

1. SSO example, I don't think that you understood. In the first example a role mapped to a non-existing Argo role, receives the policy for the role passed by the IdP.
2. local user: okay, it makes sense

[ev1lm0nk3y]

To ensure there isn't further misunderstandings, would you help clarifying the SSO example a bit more?

In the first example:

• sandbox-sso is the IdP provided role that you provided a policy for
• aaa is a random string you used which Argo now believes is a local role, but with no defined policy

Question: The SSO "user" logging in via SSO does NOT have the sandbox-sso role assigned by the IdP?

Your Example 1 (edited to clearly define where the mapping is coming from):

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    g, azure:sandbox-sso, argocd:aaa
    p, azure:sandbox-sso, applications, get, */*, allow
  policy.default: ""
  scopes: '[roles]'

Other than Applications, was the "user" able to read other Argo objects like Project or Notification?

I have had difficulty putting the documentation into practice and I had to dig into the code to find the right structure. (I've always had it in my head that g meant "group" but TIL that it means "grant"). If there are no other Project policies that may have allowed the user to get applications, I wonder if defining an Argo role without any policy caused Argo to attach a builtin policy, like default:readonly.

Might be good to get some more logging from the RBAC and SSO system to help trace this. Could you set the envvars ARGOCD_SSO_DEBUG and ARGOCD_RBAC_DEBUG to gather more details?

[Gianluca755]

Hello ev1lm0nk3y,

sorry for the long waiting. How do I set the envvars? I'm on AWS EKS and Argo CD was installed with Helm.

If I do

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    g, sandbox-developer, role:aaa
    p, sandbox-developer, applications, get, */*, allow
    p, sandbox-developer, applications, sync, */*, allow
  policy.default: ""
  scopes: '[roles, email]'

When I login I'm able to see and sync the applications while I don't have other permissions like create applications or see and create projects. So the policy default to "" seems to work.

On the other hand if I do this, all is working correctly

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    # g, sandbox-developer, role:aaa
    p, sandbox-developer, applications, get, */*, allow
    p, sandbox-developer, applications, sync, */*, allow
  policy.default: ""
  scopes: '[roles, email]'

[ev1lm0nk3y]

To set environment variables, there is usually a section for setting env for all the components. For instance, to add the envvars that I mentioned, looking at the values.yaml file shows that it can be set on the application controllers.

controller:
  env:
    - name: ARGOCD_SSO_DEBUG
      value: true
    - name: ARGOCD_RBAC_DEBUG
      value: true

As for your latest examples, they both should only allow a user to see and sync applications. From what I see, they are both configured to do that. How is the second example "working correctly"? Is the first example not expected?

[Gianluca755]

Hello @ev1lm0nk3y,

fyi I didn't find any different logs after setting ARGOCD_SSO_DEBUG, ARGOCD_RBAC_DEBUG.

To recap my IdP gives me sandbox-developer, with the following config I'm able to see and sync the applications while I don't have other permissions like create applications or see and create projects, so the policy.default = "" seems to work.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    g, sandbox-developer, role:aaa
    p, sandbox-developer, applications, get, */*, allow
    p, sandbox-developer, applications, sync, */*, allow
  policy.default: ""
  scopes: '[roles, email]'

With the following config I don't see applications or anything

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argo-cd
data:
  policy.csv: |
    ### g, sandbox-developer, role:aaa
    p, sandbox-developer, applications, get, */*, allow
    p, sandbox-developer, applications, sync, */*, allow
  policy.default: ""
  scopes: '[roles, email]'

The point is that the role:aaa has no permissions defined in the configmap, so the behavior is inconsistent between these two examples.