Authentication & Security

Authentication

GreenOps is bundled with the popular open-source software Dex as an IdP for third party SSO. This allows users to use whatever their preferred systems (Okta, Google Workspaces, Azure AD, etc.) or methods (OIDC, SAML) for access.

Configuring SSO for accessing GreenOps

To enable SSO, update the GreenOps control plane's values.yaml. In the common section, update the SSO subsection:

sso:
  enabled: false
  config:
    url: ""
    dex.config: |-
      ...

• Set enabled to true.
• url is the exact same URL defined in greenopsUrl a few lines above.
• Apply a Dex configuration to the dex.config section. If you are unfamiliar with a Dex configuration, examples can be found below. GreenOps supports OIDC, SAML, Github, Google, and Microsoft.

• Add a staticClients section below the connectors section in the Dex config (GREENOPS_URL would be the same value as url in values.yaml):

  staticClients:
    - id: greenops-sso
      name: GreenOps-SSO
      redirectURIs:
        - https://<GREENOPS_URL>/oauth2/callback
      secretEnv: GREENOPS_SSO_CLIENT_SECRET
  

Here are a few examples of a fully configured SSO section that can be copy/pasted and modified:

Auth0 with OIDCOkta with SAML

sso:
  enabled: true
  config:
    url: "https://greenops.domain.com"
    dex.config: |-
      connectors:
        - type: oidc
          id: auth0
          name: auth0
          config:
            issuer: https://prod-issuer.us.auth0.com/
            clientID: En0GVjBZsjEsctvWhk4EDfYM0CQbDlpb
            # See the note below for adding sensitive information like client secrets
            clientSecret: $<SOME_K8S_SECRET>:dex.github.clientSecret
            basicAuthUnsupported: false
            insecureSkipEmailVerified: false
            insecureEnableGroups: false
            getUserInfo: false
            scopes:
            - groups
            - email
            - profile
      staticClients:
        - id: greenops-sso
          name: GreenOps-SSO
          redirectURIs:
            - https://greenops.domain.com/oauth2/callback
          secretEnv: GREENOPS_SSO_CLIENT_SECRET

sso:
  enabled: true
  config:
    url: "https://greenops.domain.com"
    dex.config: |-
      connectors:
        - type: saml
          id: saml
          name: okta
          config:
            ssoURL: https://app-name.okta.com/app/app-name/exK3nc1ADbF/sso/saml
            # You need `caData` _OR_ `ca`, but not both.
            caData: |
              <CA cert passed through base64 encoding>
            # You need `caData` _OR_ `ca`, but not both.
            # Path to mount the secret to the dex container - this can be configured in the values.yaml file.
            ca: /path/to/ca.pem
            redirectURI: https://greenops.domain.com/api/dex/callback
            usernameAttr: email
            emailAttr: email
            groupsAttr: group
      staticClients:
        - id: greenops-sso
          name: GreenOps-SSO
          redirectURIs:
            - https://greenops.domain.com/oauth2/callback
          secretEnv: GREENOPS_SSO_CLIENT_SECRET

Note: Using secrets

Sensitive information like client secrets can be injected as Kubernetes secrets. Create a secret like:

apiVersion: v1
kind: Secret
metadata:
  name: sso-info-secret
  namespace: greenops
  labels:
    # This is very important to add. If the part-of label is not added, the secret will not be accessible.
    app.kubernetes.io/part-of: argocd
type: Opaque
data:
  ...
  # Store client secret like below.
  # Ensure the secret is base64 encoded
  clientSecret: <client-secret-base64-encoded>

The private value can then be referenced in the following format $<K8S_SECRET_NAME>:<KEY_NAME>. For the example above, it would be $sso-info-secret:clientSecret.

Note: Using volumes

The values.yaml file can be updated to include volumes (in cases like mounting certificate files). See the section here.

Re-deploy GreenOps, and use the SSO login button on login page to access GreenOps. That's it!

Authorization

Keeping in line with Argo's flexible Casbin policy, users set up robust RBAC policies using GreenOps. This allows different users to have defined permissions for creating, seeing, and managing templates, clusters, pipelines, and all other resources in the GreenOps ecosystem. The Argo CD RBAC configuration policy can be found here.

RBAC permission structure

All permission definitions follow the same format:

p, <GreenOps role>, <resource>, <action>, <object>

RBAC resources and actions

Resources:

• cluster - Whether a user can perform actions on the cluster page.
• team - Whether a user can perform actions on specific teams, or pipelines in those teams.
• block_template - Whether a user can perform actions on the block templates.
• pipeline_template - Whether a user can perform actions on the pipeline templates.
• apikey - Whether a user can perform actions on the API key used to manage a cluster.
• developer_token - Whether a user can perform actions on API tokens for dynamic management of resources.
• resume - Whether a user is allowed to resume workflows that have been suspended.
• rbac_config - Whether a user can perform actions on the RBAC policy.

The global actions are create, delete, read, update, and sync. The sync action is only available for clusters, teams, and block/pipeline templates.

The GreenOps UI gives a default RBAC policy. As an example, the following would be a valid permission:

p, role:admin, team, sync, *, allow

The permission allows a user with the admin role to sync a pipeline in any team. The action and resource (sync and *, in this case) can both be explicitly set, or use wildcard matching.

Roles and groups

Roles and groups can be configured via the UI as well. The example below defines the admin role which is linked to the default admin user in GreenOps:

g, admin, role:admin

The format is:

g, <external role/group>, <GreenOps role>

Using existing roles from identity providers

When using Github, Okta, Azure AD, or any other SSO tool, external roles/groups can be mapped to GreenOps roles. The GreenOps roles would then be included in permission definitions. This provides a very simple way to map an existing RBAC structure to GreenOps without the hassle or rewriting policies or finding a different way to manage users.