github.com/argoproj/argo-cd/v3@v3.2.1/docs/operator-manual/user-management/okta.md (about)

     1  # Okta
     2  
     3  !!! note "Are you using this? Please contribute!"
     4      If you're using this IdP please consider [contributing](../../developer-guide/docs-site.md) to this document.
     5  
     6  A working Single Sign-On configuration using Okta via at least two methods was achieved using:
     7  
     8  * [SAML (with Dex)](#saml-with-dex)
     9  * [OIDC (without Dex)](#oidc-without-dex)
    10  
    11  ## SAML (with Dex)
    12  
    13  !!! note "Okta app group assignment"
    14      The Okta app's **Group Attribute Statements** regex will be used later to map Okta groups to Argo CD RBAC roles.
    15  
    16  1. Create a new SAML application in Okta UI.
    17      * ![Okta SAML App 1](../../assets/saml-1.png)
    18          I've disabled `App Visibility` because Dex doesn't support Provider-initiated login flows.
    19      * ![Okta SAML App 2](../../assets/saml-2.png)
    20  1. Click `View setup instructions` after creating the application in Okta.
    21      * ![Okta SAML App 3](../../assets/saml-3.png)
    22  1. Copy the Argo CD URL to the `argocd-cm` in the data.url
    23  
    24  <!-- markdownlint-disable MD046 -->
    25  ```yaml
    26  data:
    27    url: https://argocd.example.com
    28  ```
    29  <!-- markdownlint-disable MD046 -->
    30  
    31  1. Download the CA certificate to use in the `argocd-cm` configuration.
    32      * If you are using this in the caData field, you will need to pass the entire certificate (including `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` stanzas) through base64 encoding, for example, `base64 my_cert.pem`.
    33      * If you are using the ca field and storing the CA certificate separately as a secret, you will need to mount the secret to the `dex` container in the `argocd-dex-server` Deployment.
    34      * ![Okta SAML App 4](../../assets/saml-4.png)
    35  1. Edit the `argocd-cm` and configure the `data.dex.config` section:
    36  
    37  <!-- markdownlint-disable MD046 -->
    38  ```yaml
    39  dex.config: |
    40    logger:
    41      level: debug
    42      format: json
    43    connectors:
    44    - type: saml
    45      id: okta
    46      name: Okta
    47      config:
    48        ssoURL: https://yourorganization.oktapreview.com/app/yourorganizationsandbox_appnamesaml_2/rghdr9s6hg98s9dse/sso/saml
    49        # You need `caData` _OR_ `ca`, but not both.
    50        caData: |
    51          <CA cert passed through base64 encoding>
    52        # You need `caData` _OR_ `ca`, but not both.
    53        # Path to mount the secret to the dex container
    54        ca: /path/to/ca.pem
    55        redirectURI: https://ui.argocd.yourorganization.net/api/dex/callback
    56        usernameAttr: email
    57        emailAttr: email
    58        groupsAttr: group
    59  ```
    60  <!-- markdownlint-enable MD046 -->
    61  
    62  ----
    63  
    64  ### Private deployment
    65  It is possible to setup Okta SSO with a private Argo CD installation, where the Okta callback URL is the only publicly exposed endpoint.
    66  The settings are largely the same with a few changes in the Okta app configuration and the `data.dex.config` section of the `argocd-cm` ConfigMap.
    67  
    68  Using this deployment model, the user connects to the private Argo CD UI and the Okta authentication flow seamlessly redirects back to the private UI URL.
    69  
    70  Often this public endpoint is exposed through an [Ingress object](../../ingress/#private-argo-cd-ui-with-multiple-ingress-objects-and-byo-certificate).
    71  
    72  
    73  1. Update the URLs in the Okta app's General settings
    74      * ![Okta SAML App Split](../../assets/saml-split.png)
    75          The `Single sign on URL` field points to the public exposed endpoint, and all other URL fields point to the internal endpoint.
    76  1. Update the `data.dex.config` section of the `argocd-cm` ConfigMap with the external endpoint reference.
    77  
    78  <!-- markdownlint-disable MD046 -->
    79  ```yaml
    80  dex.config: |
    81    logger:
    82      level: debug
    83    connectors:
    84    - type: saml
    85      id: okta
    86      name: Okta
    87      config:
    88        ssoURL: https://yourorganization.oktapreview.com/app/yourorganizationsandbox_appnamesaml_2/rghdr9s6hg98s9dse/sso/saml
    89        # You need `caData` _OR_ `ca`, but not both.
    90        caData: |
    91          <CA cert passed through base64 encoding>
    92        # You need `caData` _OR_ `ca`, but not both.
    93        # Path to mount the secret to the dex container
    94        ca: /path/to/ca.pem
    95        redirectURI: https://external.path.to.argocd.io/api/dex/callback
    96        usernameAttr: email
    97        emailAttr: email
    98        groupsAttr: group
    99  ```
   100  <!-- markdownlint-enable MD046 -->
   101  
   102  ### Connect Okta Groups to Argo CD Roles
   103  Argo CD is aware of user memberships of Okta groups that match the *Group Attribute Statements* regex.
   104  The example above uses the `argocd-*` regex, so Argo CD would be aware of a group named `argocd-admins`.
   105  
   106  Modify the `argocd-rbac-cm` ConfigMap to connect the `argocd-admins` Okta group to the builtin Argo CD `admin` role.
   107  <!-- markdownlint-disable MD046 -->
   108  ```yaml
   109  apiVersion: v1
   110  kind: ConfigMap
   111  metadata:
   112    name: argocd-rbac-cm
   113  data:
   114    policy.csv: |
   115      g, argocd-admins, role:admin
   116    scopes: '[email,groups]'
   117  ```
   118  
   119  ## OIDC (without Dex)
   120  
   121  !!! warning "Okta groups for RBAC"
   122      If you want `groups` scope returned from Okta, you will need to enable [API Access Management with Okta](https://developer.okta.com/docs/concepts/api-access-management/). This addon is free, and automatically enabled, on Okta developer edition. However, it's an optional add-on for production environments, with an additional associated cost.
   123  
   124      You may alternately add a "groups" scope and claim to the default authorization server, and then filter the claim in the Okta application configuration. It's not clear if this requires the Authorization Server add-on.
   125  
   126      If this is not an option for you, use the [SAML (with Dex)](#saml-with-dex) option above instead.
   127  
   128  !!! note
   129      These instructions and screenshots are of Okta version 2023.05.2 E. You can find the current version in the Okta website footer.
   130  
   131  First, create the OIDC integration:
   132  
   133  1. On the `Okta Admin` page, navigate to the Okta Applications at `Applications > Applications.`
   134  1. Choose `Create App Integration`, and choose `OIDC`, and then `Web Application` in the resulting dialogues.
   135      ![Okta OIDC app dialogue](../../assets/okta-create-oidc-app.png)
   136  1. Update the following:
   137      1. `App Integration name` and `Logo` - set these to suit your needs; they'll be displayed in the Okta catalogue.
   138      1. `Sign-in redirect URLs`: Add `https://argocd.example.com/auth/callback`; replacing `argocd.example.com` with your ArgoCD web interface URL.
   139      1. `Sign-out redirect URIs`: Add `https://argocd.example.com`; substituting the correct domain name as above. 
   140      1. Either assign groups, or choose to skip this step for now.
   141      1. Leave the rest of the options as-is, and save the integration.
   142      ![Okta app settings](../../assets/okta-app.png)
   143  1. Copy the `Client ID` and the `Client Secret` from the newly created app; you will need these later.
   144  
   145  Next, create a custom Authorization server:
   146  
   147  1. On the `Okta Admin` page, navigate to the Okta API Management at `Security > API`.
   148  1. Click `Add Authorization Server`, and assign it a name and a description. The `Audience` should match your ArgoCD URL - `https://argocd.example.com`
   149  1. Click `Scopes > Add Scope`:
   150      1. Add a scope called `groups`. Leave the rest of the options as default.
   151      ![Groups Scope](../../assets/okta-groups-scope.png)
   152  1. Click `Claims > Add Claim`:
   153      1. Add a claim called `groups`.
   154      1. Adjust the `Include in token type` to `ID Token`, `Always`.
   155      1. Adjust the `Value type` to `Groups`.
   156      1. Add a filter that will match the Okta groups you want passed on to ArgoCD; for example `Regex: argocd-.*`.
   157      1. Set `Include in` to `groups` (the scope you created above).
   158      ![Groups Claim](../../assets/okta-groups-claim.png)
   159  1. Click on `Access Policies` > `Add Policy.` This policy will restrict how this authorization server is used.
   160      1. Add a name and description.
   161      1. Assign the policy to the client (application integration) you created above. The field should auto-complete as you type.
   162      1. Create the policy.
   163      ![Auth Policy](../../assets/okta-auth-policy.png)
   164  1. Add a rule to the policy:
   165      1. Add a name; `default` is a reasonable name for this rule.
   166      1. Fine-tune the settings to suit your organization's security posture. Some ideas:
   167          1. uncheck all the grant types except the Authorization Code.
   168          1. Adjust the token lifetime to govern how long a session can last.
   169          1. Restrict refresh token lifetime, or completely disable it.
   170      ![Default rule](../../assets/okta-auth-rule.png)
   171  1. Finally, click `Back to Authorization Servers`, and copy the `Issuer URI`. You will need this later.
   172  
   173  ### CLI login
   174  
   175  In order to login with the CLI `argocd login https://argocd.example.com --sso`, Okta requires a separate dedicated App Integration:
   176  
   177  1. Create a new `Create App Integration`, and choose `OIDC`, and then `Single-Page Application`.
   178  1. Update the following:
   179      1. `App Integration name` and `Logo` - set these to suit your needs; they'll be displayed in the Okta catalogue.
   180      1. `Sign-in redirect URLs`: Add `http://localhost:8085/auth/callback`.
   181      1. `Sign-out redirect URIs`: Add `http://localhost:8085`.
   182      1. Either assign groups, or choose to skip this step for now.
   183      1. Leave the rest of the options as-is, and save the integration.
   184      1. Copy the `Client ID` from the newly created app; `cliClientID: <Client ID>` will be used in your `argocd-cm` ConfigMap.
   185  1. Edit your Authorization Server `Access Policies`:
   186      1. Navigate to the Okta API Management at `Security > API`.
   187      1. Choose your existing `Authorization Server` that was created previously.
   188      1. Click `Access Policies` > `Edit Policy`.
   189      1. Assign your newly created `App Integration` by filling in the text box and clicking `Update Policy`.
   190      ![Edit Policy](../../assets/okta-auth-policy-edit.png)
   191  
   192  If you haven't yet created Okta groups, and assigned them to the application integration, you should do that now:
   193  
   194  1. Go to `Directory > Groups`
   195  1. For each group you wish to add:
   196      1. Click `Add Group`, and choose a meaningful name. It should match the regex or pattern you added to your custom `group` claim.
   197      1. Click on the group (refresh the page if the new group didn't show up in the list).
   198      1. Assign Okta users to the group.
   199      1. Click on `Applications` and assign the OIDC application integration you created to this group.
   200      1. Repeat as needed.
   201  
   202  Finally, configure ArgoCD itself. Edit the `argocd-cm` configmap:
   203  
   204  <!-- markdownlint-disable MD046 -->
   205  ```yaml
   206  url: https://argocd.example.com
   207  oidc.config: |
   208    name: Okta
   209    # this is the authorization server URI
   210    issuer: https://example.okta.com/oauth2/aus9abcdefgABCDEFGd7
   211    clientID: 0oa9abcdefgh123AB5d7
   212    cliClientID: gfedcba0987654321GEFDCBA # Optional if using the CLI for SSO
   213    clientSecret: ABCDEFG1234567890abcdefg
   214    requestedScopes: ["openid", "profile", "email", "groups"]
   215    requestedIDTokenClaims: {"groups": {"essential": true}}
   216  ```
   217  
   218  You may want to store the `clientSecret` in a Kubernetes secret; see [how to deal with SSO secrets](./index.md/#sensitive-data-and-sso-client-secrets ) for more details.