ArgoCD: Okta integration, and user groups

In the previous post ArgoCD: users, access, and RBAC we’ve checked how to manage users and their permissions in ArgoCD, now let’s add an SSO authentification.

The idea is that we don’t add user accounts locally in the ArgoCD’s ConfigMap, but instead will use our Okta users databases and Okta will perform their authentication. And on the ArgoCD side will do users’ authorization, i.e. will check their permission boundaries.

Also, by using the SSO we will be able to create user groups that will have various roles tied to specific Projects.

We will use the SAML (with Dex), see also the What is: SAML — an overview, its structure and requests tracing between a Jenkins and Okta SSO post for more details on the SAML.

• Okta configuration
• ArgoCD configuration
• Roles, and user groups in ArgoCD
• ArgoCD CLI login
• Errors and problems
• Bad Request — User session error
• Failed to authenticate: no attribute with name “group”: [email]

Okta configuration

Go to your Okta account, and create a SAML application:

For the logo, I’ve used this pic:

On the next page, set the following:

• Single sign on URL and
• Audience URI (SP Entity ID):
• your ArgoCD URL like argourl.com/api/dex/callback
• в Attribute Statements: name — email, format Basic, Value — user.email
• в Group Attribute Statements: name — group, format Basic, in the Filter you can use a regex as it’s shown in the documentation — then, Okta groups will be filtered before passing them to the ArgoCD during Authentication context, or filter nothing by setting the regex as “*”:

Or you can filter a list of groups by using the |:

On the next page, set the I’m an Okta customer adding an internal app, and click Finish:

Assign the Application to a user or group:

Switch to the Sign On tab, and click on the View Setup Instructions button:

Now, let’s go to our ArgoCD instance.

ArgoCD configuration

Edit the argocd-cm ConfigMap:

$ kubectl -n dev-1–18-devops-argocd-ns edit configmap argocd-cm

Set:

• url: (can be already set, just check its value) — ArgoCD’s instance external URL
• ssoURL: Identity Provider Single Sign-On URL from the page that was opened after you’ve clicked the View Setup Instructions button
• caData: an Okta’s certificate from the same page encoded with base64, for example on the https://www.base64encode.org site

Now, your config will look like this:

apiVersion: v1
data:
  url: [https://dev-1-18.argocd.example.com](https://dev-1-18.argocd.example.com)
  dex.config: |
    logger:
      level: debug
      format: json
    connectors:
    - type: saml
      id: okta
      name: Okta
      config:
        ssoURL: [https://okta.example.com/app/appname/exk9f6o07dKjN0huC357/sso/saml](https://okta.example.com/app/appname/exk9f6o07dKjN0huC357/sso/saml)
        caData: |
          LS0tLS***FLS0tLS0=
        usernameAttr: email
        emailAttr: email
        groupsAttr: group
...

Roles, and user groups in ArgoCD

Edit the argocd-rbac-cm ConfigMap, add the DevOps group (will get from the Okta) mapping to the role:admin:

g, DevOps, role:admin

Also, here you can disable the admin user, and add Backend and Web groups bindings to applications on their projects:

...
data:
  admin.enabled: "false"
  policy.csv: |
    p, role:backend-app-admin, applications, *, Backend/*, allow
    p, role:web-app-admin, applications, *, Web/*, allow
    g, DevOps, role:admin
  policy.default: role:''
  scopes: '[email,groups]'
...

Keep in mind, that RBAC is case sensitive, so DevOps != devops. So you have to specify a group here the same as it is set in the Okta.

Save, and try to log in:

ArgoCD CLI login

To use CLI with SSO, just add the --sso option, and in the --username - specify your Okta's login:

$ argocd login dev-1–18.argocd.example.com --sso --username [e-mail]
Opening browser for authentication
…
Authentication successful
‘[e-mail]’ logged in successfully
Context ‘dev-1–18.argocd.example.com’ updated

A default browser will be opened to authenticate you with Okta.

Errors and problems

Bad Request — User session error

When using the Dex keep in mind, that it doesn’t allow the Provider-initated login, i.e. you can log in to the ArgoCD instance from your Okta — you’ll get the 400 error:

Thus, worth hiding the application from users:

Failed to authenticate: no attribute with name “group”: [email]

In case of error like “Failed to authenticate: no attribute with name “group”: [email]”:

Use the saml-chrome-panel, and check attributes that are sent in the AttributeStatement from the Okta:

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">[e-mail]</saml2:AttributeValue>
    </saml2:Attribute>
</saml2:AttributeStatement>

In this example, I’ve made a misprint in the Okta config and it doesn’t send the <saml2:Attribute Name="group"> attribute.

The entry must be like the next:

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml2:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">[e-mail]</saml2:AttributeValue>
    </saml2:Attribute>
    <saml2:Attribute Name="group" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">DevOps</saml2:AttributeValue>
    </saml2:Attribute>
</saml2:AttributeStatement>

Done.

Originally published at RTFM: Linux, DevOps, and system administration.

---