v2.9 and after
It is possible to use Dex for authentication. This document describes how to set up ArgoWorkflows and ArgoCD so that ArgoWorkflows uses ArgoCD's Dex server for authentication.
Firstly, configure the settings workflow-controller-configmap.yaml with the correct OAuth 2 values. If working towards an oidc configuration the ArgoCD project has guides on its similar (though different) process for setting up oidc providers. It also includes examples for specific providers.
Next, create the k8s secrets for holding the OAuth2 client-id and client-secret. You may refer to the kubernetes documentation on Managing secrets. For example by using kubectl with literals:
kubectl create secret -n argo generic client-id-secret \
--from-literal=client-id-key=foo
kubectl create secret -n argo generic client-secret-secret \
--from-literal=client-secret-key=bar
Then, start the Argo Server using the SSO auth mode:
argo server --auth-mode sso --auth-mode ...
v2.12 and after
As of v2.12 we issue a JWE token for users rather than give them the ID token from your OAuth2 provider. This token is opaque and has a longer expiry time (10h by default).
The token encryption key is automatically generated by the Argo Server and stored in a Kubernetes secret name "sso".
You can revoke all tokens by deleting the encryption key and restarting the Argo Server (so it generates a new key).
kubectl delete secret sso
!!! Warning The old key will be in the memory the any running Argo Server, and they will therefore accept and user with token encrypted using the old key. Every Argo Server MUST be restarted.
All users will need to log in again. Sorry.
v2.12 and after
You can optionally add RBAC to SSO. This allows you to give different users different access levels. Except for client auth mode, all users of the Argo Server must ultimately use a service account. So we allow you to define rules that map a user (maybe using their OIDC groups) to a service account in the same namespace as argo server by annotating the service account.
To allow service accounts to manage resources in other namespaces create a role and role binding in the target namespace.
RBAC config is installation-level, so any changes will need to be made by the team that installed Argo. Many complex rules will be burdensome on that team.
Firstly, enable the rbac: setting in workflow-controller-configmap.yaml. You almost certainly want to be able configure RBAC using groups, so add scopes: to the SSO settings:
sso:
# ...
scopes:
- groups
rbac:
enabled: true!!! Note Not all OIDC provider support the groups scope. Please speak to your provider about their options.
To configure a service account to be used, annotate it:
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
annotations:
# The rule is an expression used to determine if this service account
# should be used.
# * `groups` - an array of the OIDC groups
# * `iss` - the issuer ("argo-server")
# * `sub` - the subject (typically the username)
# Must evaluate to a boolean.
# If you want an account to be the default to use, this rule can be "true".
# Details of the expression language are available in
# https://github.com/antonmedv/expr/blob/master/docs/Language-Definition.md.
workflows.argoproj.io/rbac-rule: "'admin' in groups"
# The precedence is used to determine which service account to use whe
# Precedence is an integer. It may be negative. If omitted, it defaults to "0".
# Numerically higher values have higher precedence (not lower, which maybe
# counter-intuitive to you).
# If two rules match and have the same precedence, then which one used will
# be arbitrary.
workflows.argoproj.io/rbac-rule-precedence: "1"If no rule matches, we deny the user access.
!!! Tip You'll probably want to configure a default account to use if no other rule matches, e.g. a read-only account, you can do this as follows:
```yaml
metadata:
name: read-only
annotations:
workflows.argoproj.io/rbac-rule: "true"
workflows.argoproj.io/rbac-rule-precedence: "0"
```
The precedence must be the lowest of all your service accounts.
v2.12 and after
By default, your SSO session will expire after 10 hours. You can change this by adding a sessionExpiry value to your workflow-controller-configmap.yaml under the SSO heading.
sso:
# Expiry defines how long your login is valid for in hours. (optional)
sessionExpiry: 240hv3.1.4 and after
If your OIDC provider provides groups information with a claim name other than groups, you could configure config-map to specify custom claim name for groups. Argo now arbitary custom claims and any claim can be used for expr eval. However, since group information is displayed in UI, it still needs to be an array of strings with group names as elements.
customClaim in this case will be mapped to groups key and we can use the same key groups for evaluating our expressions
sso:
# Specify custom claim name for OIDC groups.
customGroupClaimName: argo_groupsIf your OIDC provider provides groups information only using the userInfo endpoint (e.g. OKta), you could configure userInfoPath to specify the user info endpoint that contains the groups claim.
sso:
userInfoPath: /oauth2/v1/userinfo# assuming customClaimGroupName: argo_groups
workflows.argoproj.io/rbac-rule: "'argo_admins' in groups"