March 14, 2025 10 min to read

Setting up ArgoCD SSO with GitLab

A comprehensive guide to implementing ArgoCD SSO with GitLab

Overview

In the last post, I tried configuring ArgoCD SSO using Google Oauth,

This post explains how to configure Single Sign-On (SSO) for ArgoCD using GitLab. We’ll walk through the process of setting up GitLab OAuth and integrating it with ArgoCD.

Benefits of GitLab SSO Integration

Unified Authentication
Allows developers to use their existing GitLab credentials for ArgoCD access.
Streamlined Access Management
Leverages GitLab's groups and user management for ArgoCD authorization.
Improved Developer Experience
Eliminates the need to manage separate credentials for GitLab and ArgoCD.
Consistent Permissions
GitLab groups can be mapped directly to ArgoCD roles for consistent access control.

Prerequisites

GitLab instance
ArgoCD installed on a Kubernetes cluster
Administrative access to both GitLab and ArgoCD
Properly configured DNS for ArgoCD server

Steps

1. Create GitLab Application

Console Method

Navigate to Admin Area > Applications in GitLab
Create new application:
- Name: Argo CD
- Redirect URI: https://argocd-server-urlapi/dex/callback
- Select Scopes:
  - read_user
  - openid
  - profile
  - email
Save the credentials:

Application ID (Client ID)
Secret (Client Secret)

Command Line Setup

If you’re using GitLab API to create the application:

GitLab Application Security Considerations

Application Security Tips:

1. Scopes Selection: - Only select required scopes (read_user, openid, profile, email)
- Avoid adding unnecessary permissions

2. Application Configuration: - Use a descriptive application name for audit purposes
- Consider setting application expiration date for security
- Rotate client secrets periodically

3. Access Management: - Limit admin access to GitLab application settings
- Document the integration for security reviews

2. Configure ArgoCD Installation

Create values/mgmt.yaml:

global:
  domain: argocd.your-domain.com

configs:
  params:
    create: true
    server.insecure: true

  ssh:
    extraHosts: |
      gitlab.concrit.us ssh-rsa AAAAB3N...
      gitlab.concrit.us ecdsa-sha2-nistp256...
      gitlab.concrit.us ssh-ed25519 AAAA..

controller:
  replicas: 1

dex:
  enabled: true

redis:
  enabled: true

server:
  replicas: 1
  ingress:
    enabled: true
    annotations:
      nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
      nginx.ingress.kubernetes.io/ssl-passthrough: "false"
    ingressClassName: "nginx"
    path: /
    pathType: Prefix

repoServer:
  replicas: 1

applicationSet:
  replicas: 1

notifications:
  enabled: true

3. Configure GitLab SSO

Update values/mgmt.yaml with SSO configuration:

configs:
  cm:
    timeout.reconciliation: 60s
    dex.config: |
      connectors:
        - type: gitlab
          id: gitlab
          name: GitLab
          config:
            baseURL: <gitlab url>
            clientID: <application id>
            clientSecret: <secret>
            redirectURI: https://<argocd url>/api/dex/callback
            groups:
              - server
              
  rbac:
    create: true
    policy.csv: |
      p, role:org-admin, applications, *, */*, allow
      p, role:org-admin, clusters, get, *, allow
      p, role:org-admin, repositories, *, *, allow
      p, role:org-admin, projects, get, *, allow
      p, role:org-admin, logs, get, *, allow
      p, role:org-admin, exec, create, */*, allow
      
      g, <group>, role:org-admin

  secrets:
    dex.gitlab.clientId: "<application id>"
    dex.gitlab.clientSecret: "<secret>"

Apply the changes:

helm upgrade argocd . -n argocd -f ./values/mgmt.yaml
kubectl rollout restart -n argocd deployment argocd-dex-server

Access your ArgoCD instance and verify GitLab SSO login works correctly.

Advanced GitLab SSO Configuration

Role-Based Access Control with GitLab Groups

You can map different GitLab groups to different ArgoCD roles for granular access control:

configs:
  rbac:
    policy.csv: |
      # Administrators with full access
      p, role:admin, applications, *, */*, allow
      p, role:admin, clusters, *, *, allow
      p, role:admin, repositories, *, *, allow
      p, role:admin, projects, *, *, allow
      p, role:admin, accounts, *, *, allow
      p, role:admin, gpgkeys, *, *, allow
      p, role:admin, logs, *, *, allow
      p, role:admin, exec, *, *, allow
      p, role:admin, certificates, *, *, allow
      
      # DevOps team with broad access but not admin
      p, role:devops, applications, *, */*, allow
      p, role:devops, clusters, get, *, allow
      p, role:devops, repositories, *, *, allow
      p, role:devops, logs, *, *, allow
      p, role:devops, exec, create, */*, allow
      
      # Developers with limited access
      p, role:developer, applications, get, */*, allow
      p, role:developer, applications, sync, */*, allow
      p, role:developer, repositories, get, *, allow
      p, role:developer, logs, get, */*, allow
      
      # Map GitLab groups to roles
      g, gitlab:platform-admin, role:admin
      g, gitlab:devops-team, role:devops
      g, gitlab:developers, role:developer

Project-Specific Access Control

You can also configure access to specific ArgoCD projects:

configs:
  rbac:
    policy.csv: |
      # Team A access to Team A projects only
      p, role:team-a, applications, *, team-a/*, allow
      p, role:team-a, logs, *, team-a/*, allow
      g, gitlab:team-a, role:team-a
      
      # Team B access to Team B projects only
      p, role:team-b, applications, *, team-b/*, allow
      p, role:team-b, logs, *, team-b/*, allow
      g, gitlab:team-b, role:team-b

Using GitLab Subgroups

If you have GitLab subgroups, you can map them in ArgoCD:

configs:
  cm:
    dex.config: |
      connectors:
        - type: gitlab
          id: gitlab
          name: GitLab
          config:
            baseURL: https://gitlab.your-domain.com
            clientID: <application_id>
            clientSecret: <secret>
            redirectURI: https://argocd.your-domain.com/api/dex/callback
            groups:
              - engineering/backend
              - engineering/frontend
              - operations/platform

Manual Installation and Configuration

If you’re not using Helm, here’s how to configure ArgoCD manually:

1. Create argocd-cm ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  url: https://argocd.your-domain.com
  dex.config: |
    connectors:
      - type: gitlab
        id: gitlab
        name: GitLab
        config:
          baseURL: https://gitlab.your-domain.com
          clientID: <application_id>
          clientSecret: $dex.gitlab.clientSecret
          redirectURI: https://argocd.your-domain.com/api/dex/callback
          groups:
            - devops
            - engineering

2. Create argocd-secret for GitLab Credentials

# Convert client secret to base64
GITLAB_CLIENT_SECRET_BASE64=$(echo -n "your-gitlab-client-secret" | base64)

# Apply the secret
kubectl patch secret argocd-secret -n argocd --type=json -p='[{"op": "add", "path": "/data/dex.gitlab.clientSecret", "value":"'$GITLAB_CLIENT_SECRET_BASE64'"}]'

3. Configure RBAC

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |
    p, role:org-admin, applications, *, */*, allow
    p, role:org-admin, clusters, get, *, allow
    p, role:org-admin, repositories, *, *, allow
    p, role:org-admin, projects, get, *, allow
    p, role:org-admin, logs, get, *, allow
    p, role:org-admin, exec, create, */*, allow
    
    g, gitlab:devops, role:org-admin
  policy.default: role:readonly
  scopes: "[groups, email]"

Troubleshooting GitLab SSO

Common Issues and Solutions:

1. Authentication Failed: - Verify client ID and secret match GitLab application
- Check baseURL points to correct GitLab instance
- Ensure redirectURI matches exactly (including trailing slash)
- Verify required scopes are enabled in GitLab application

2. User Successfully Authenticates but Has No Access: - Check if user belongs to the correct GitLab group
- Verify groups are correctly mapped in RBAC policy
- Confirm 'groups' is included in scopes setting
- Check ArgoCD logs for group claim issues

3. Redirect URI Error: - Double check the redirect URI in both GitLab and ArgoCD config
- Ensure the ArgoCD server is accessible at the configured URL
- Check for TLS/SSL certificate issues

4. Timeout During Authentication: - Check network connectivity between ArgoCD and GitLab
- Verify GitLab instance is running and accessible
- Check for firewall or proxy issues

Debugging Steps

# Check Dex logs for authentication issues
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-dex-server

# Check ArgoCD server logs
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-server

# Verify configuration
kubectl get configmap argocd-cm -n argocd -o yaml
kubectl get configmap argocd-rbac-cm -n argocd -o yaml

# Check if secret is properly configured (will be masked)
kubectl get secret argocd-secret -n argocd -o yaml

Self-Hosted GitLab SSL Issues

If you’re using a self-signed certificate with GitLab, you may need to add it to ArgoCD:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  # ... existing config ...
  dex.config: |
    connectors:
      - type: gitlab
        id: gitlab
        name: GitLab
        config:
          baseURL: https://gitlab.your-domain.com
          clientID: <application_id>
          clientSecret: $dex.gitlab.clientSecret
          redirectURI: https://argocd.your-domain.com/api/dex/callback
          groups:
            - devops
          # For self-signed certificates:
          insecureSkipVerify: true

Note: Using insecureSkipVerify: true is not recommended for production environments. Instead, properly configure certificates.

Security Best Practices

Security Recommendations:

1. Access Control: - Implement least privilege principle in RBAC policies
- Regularly audit group memberships in GitLab
- Periodically review ArgoCD access

2. Credentials Management: - Rotate GitLab client secret periodically
- Store secrets in Kubernetes secrets, not in plain text
- Consider using a secrets management solution

3. Network Security: - Use HTTPS for all communication
- Implement network policies in Kubernetes
- Consider IP restrictions if applicable

4. Audit and Monitoring: - Enable and review audit logs
- Set up alerts for unauthorized access attempts
- Monitor SSO configuration changes

Automation Script

Here’s a script to automate GitLab SSO configuration:

Authentication Processes

OAuth Authentication
SAML Authentication
OpenID Connect Authentication

Important Notes

Consider domain settings, security policies, and network configurations
Keep up with the latest documentation as GitLab and ArgoCD settings may change
Ensure proper backup before making configuration changes
Key points for SSO configuration:
- dex.config: Authentication configuration
- rbac: Permission settings
- Proper mapping between GitLab groups and ArgoCD roles
For enterprise environments:
- Consider implementing session timeouts
- Set up a disaster recovery plan for authentication
- Document the SSO configuration and approval workflow

somaz v3.1.2

Setting up ArgoCD SSO with GitLab

Overview

Benefits of GitLab SSO Integration

Prerequisites

Steps

1. Create GitLab Application

Command Line Setup

GitLab Application Security Considerations

2. Configure ArgoCD Installation

3. Configure GitLab SSO

Advanced GitLab SSO Configuration

Role-Based Access Control with GitLab Groups

Project-Specific Access Control

Using GitLab Subgroups

Manual Installation and Configuration

1. Create argocd-cm ConfigMap

2. Create argocd-secret for GitLab Credentials

3. Configure RBAC

Troubleshooting GitLab SSO

Debugging Steps

Self-Hosted GitLab SSL Issues

Security Best Practices

Automation Script

Authentication Processes

References

Introduction to MinIO - High Performance Object Storage

Somaz

Comments

Setting up ArgoCD SSO with GitLab

Overview

Benefits of GitLab SSO Integration

Prerequisites

Steps

1. Create GitLab Application

Command Line Setup

GitLab Application Security Considerations

2. Configure ArgoCD Installation

3. Configure GitLab SSO

4. Test Login

Advanced GitLab SSO Configuration

Role-Based Access Control with GitLab Groups

Project-Specific Access Control

Using GitLab Subgroups

Manual Installation and Configuration

1. Create argocd-cm ConfigMap

2. Create argocd-secret for GitLab Credentials

3. Configure RBAC

Troubleshooting GitLab SSO

Debugging Steps

Self-Hosted GitLab SSL Issues

Security Best Practices

Automation Script

Authentication Processes

References

Introduction to MinIO - High Performance Object Storage

Share

Somaz

Comments