Open LoricAndre opened 2 years ago
alexec
commented
2 years ago Can you be more specific? For example, do you go into the UI, and are allowed to update a workflow?
What is your Kubernetes provider? Does it both support and have RBAC enabled correctly? E.g. Docker for Desktop does not support RBAC. Certain cloud configurations don't either.
LoricAndre
commented
2 years ago Hi, thank you for that quick answer.
I can get into the UI without issues and the SSO SA is correctly assigned, which I can see in the User tab. The issue is that once logged in, I can create and submit workflows without any error.
My Kubernetes provider is Azure AKS, and RBAC is enabled and used successfully in other projects.
alexec
commented
2 years ago I think this is most likely to be mis-configuration, so I'm don't want to invest too much time until we've checked that.
kubectl auth can-i?If that fails, please book 30m via the new issue link.
alexec
commented
2 years ago Attempted to repro, failed:
argo-server | time="2022-04-07T14:38:12.194Z" level=info msg="selected SSO RBAC service account for user" email=kilgore@kilgore.trout loginServiceAccount=nothing serviceAccount=nothing ssoDelegated=false ssoDelegationAllowed=false subject=Cg0wLTM4NS0yODA4OS0wEgRtb2Nr
argo-server | time="2022-04-07T14:38:12.206Z" level=warning msg="finished unary call with code PermissionDenied" error="rpc error: code = PermissionDenied desc = workflows.argoproj.io is forbidden: User \"system:serviceaccount:argo:nothing\" cannot list resource \"workflows\" in API group \"argoproj.io\" in the namespace \"argo\"" grpc.code=PermissionDenied grpc.method=ListWorkflows grpc.service=workflow.WorkflowService grpc.start_time="2022-04-07T14:38:12-07:00" grpc.time_ms=13.813 span.kind=server system=grpc kubectl auth can-i create workflows --as=system:serviceaccount:argo:nothing -n argo
noI think this is most likely to be mis-configuration, so I'm don't want to invest too much time until we've checked that.
- Can you confirm that the correct service account in being recieved by the Kubernetes API Server by checking your logs.
It is, my email is associated with:
loginServiceAccount=argo-workflow-default-user-login serviceAccount=argo-workflow-default-user-login ssoDelegated=false ssoDelegationAllowed=false
- Can you double-check the service account using
kubectl auth can-i?
Impersonation is disabled on the cluster, I cannot test this.
qtheya
commented
1 year ago time="2023-07-13T09:08:42.134Z" level=info msg="selected SSO RBAC service account for user" email=****@****.** loginServiceAccount=tmp-sso-argo-workflows serviceAccount=tmp-sso-argo-workflows ssoDelegated=false ssoDelegationAllowed=false subject=**********
time="2023-07-13T09:08:42.135Z" level=info msg="selected SSO RBAC service account for user" email=****@****.** loginServiceAccount=tmp-sso-argo-workflows serviceAccount=tmp-sso-argo-workflows ssoDelegated=false ssoDelegationAllowed=false subject=**********
time="2023-07-13T09:08:42.139Z" level=info msg="tracking UI usage️️" email=****@****.** name=openedSensorList subject=**********
time="2023-07-13T09:08:42.139Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=CollectEvent grpc.service=info.InfoService grpc.start_time="2023-07-13T09:08:42Z" grpc.time_ms=6.564 span.kind=server system=grpckubectl auth can-i list sensors --as=system:serviceaccount:argo:tmp-sso-argo-workflows -n argo
no---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: argo:operator
rules:
- apiGroups:
- argoproj.io
resources:
- workflowtemplates
resourceNames:
- ci-k8s
- ci-protobuf
- ci-python
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods/log
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: "tmp-sso-argo:operator"
subjects:
- kind: ServiceAccount
name: tmp-sso-argo-workflows
namespace: argo
roleRef:
kind: Role
name: argo:operator
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: "tmp-sso-argo-workflows"
annotations:
workflows.argoproj.io/rbac-rule: "'*****:****' in groups"
workflows.argoproj.io/rbac-rule-precedence: "0"
secrets:
- name: github-sso-argo-workflows
umi0410
commented
1 year ago @qtheya Does your comment(https://github.com/argoproj/argo-workflows/issues/8310#issuecomment-1633869767) mean that you succeeded to reproduce the bug?
qtheya
commented
1 year ago @qtheya Does your comment(https://github.com/argoproj/argo-workflows/issues/8310#issuecomment-1633869767) mean that you succeeded to reproduce the bug?
Yes
gordonswing
commented
3 months ago Having the same issue
VLukyanov84
commented
2 months ago Came here as have the same issue.
Checklist
* [x] Double-checked my configuration. * [x] Tested using the latest version. * [x] Used the Emissary executor. ## Summary What happened/what you expected to happen? After setting up SSO and RBAC, SSO is working and assigning me the right ServiceAccount, but the rights I have on the server are more open than the associated role gives. This is my RBAC SA/Role/RoleBinding: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: argo-workflow-default-user-login namespace: {{ .Release.Namespace }} annotations: workflows.argoproj.io/rbac-rule: "'my_group' in groups" workflows.argoproj.io/rbac-rule-precedence: "0" # if the user is not in my_group, he should not and cannot access the server --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: argo-workflow-reader namespace: {{ .Release.Namespace }} rules: - apiGroups: - argoproj.io resources: - workflows - workfloweventbindings - workflowtemplates - cronworkflows - cronworkflows/finalizers verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: argo-workflow-reader namespace: {{ .Release.Namespace }} subjects: - kind: ServiceAccount name: argo-workflow-default-user-login roleRef: kind: Role name: argo-workflow-reader apiGroup: rbac.authorization.k8s.io ``` What version are you running? v3.3.1 ## Diagnostics Paste the smallest workflow that reproduces the bug. We must be able to run the workflow. ```yaml Any workflow ``` ```bash # Logs for the workflow controller: time="2022-04-04T12:05:38.101Z" level=info msg="Update leases 200" time="2022-04-04T12:05:41.374Z" level=info msg="Watch workflowtemplates 200" time="2022-04-04T12:05:43.117Z" level=info msg="Get leases 200" time="2022-04-04T12:05:43.127Z" level=info msg="Update leases 200" time="2022-04-04T12:05:48.138Z" level=info msg="Get leases 200" time="2022-04-04T12:05:48.147Z" level=info msg="Update leases 200" time="2022-04-04T12:05:52.939Z" level=info msg="List workflows 200" time="2022-04-04T12:05:52.939Z" level=info msg=healthz age=5m0s err="Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.