Integrating AWS IAM Identity Center (SSO) with Argo CD and Argo Workflows using SAML 2.0: A Step-by-Step Guide

As organizations increasingly adopt GitOps practices for managing Kubernetes deployments, tools like Argo CD and Argo Workflows have become essential in the modern cloud-native ecosystem. Argo CD automates application deployments declaratively from Git repositories, while Argo Workflows orchestrates complex, scalable pipelines and batch jobs on Kubernetes.

To make these tools secure and user-friendly, especially in enterprise environments, integrating AWS IAM Identity Center (formerly known as AWS SSO) via SAML 2.0 provides centralized authentication, group-based access control, and single sign-on (SSO) experience. This eliminates multiple logins, reduces credential sprawl, and aligns with zero-trust security principles.

In this blog post, I'll walk you through the complete setup in a clear, beginner-friendly way — perfect for freshers learning GitOps, experienced DevOps engineers hardening access, or teams pursuing CNCF and AWS community contributions. The guide draws from the official Argo CD documentation and practical implementations, updated for 2026 best practices.

Why Integrate AWS IAM Identity Center with Argo CD and Argo Workflows?

• Centralized Access Management — Manage users and groups in one place (AWS IAM Identity Center) for consistent policies across AWS services and third-party apps.

• Enhanced Security — Leverage SAML 2.0 federation to avoid storing local credentials; enforce MFA and compliance easily.

• Improved User Experience — Users log in once with corporate credentials and access Argo CD's UI and Argo Workflows seamlessly.

• Group-Based RBAC — Map AWS groups to Argo roles (e.g., readonly vs. admin) for fine-grained permissions.

Architecture Overview

User → AWS IAM Identity Center (IdP) → SAML Assertion → Argo CD Dex (bundled OIDC provider) → Argo CD / Argo Workflows (Service Providers)

Argo CD uses Dex (its embedded identity broker) to handle SAML, while Argo Workflows can federate via the same Dex instance for shared SSO.

High-Level Architecture

User logs in via corporate credentials → AWS IAM Identity Center authenticates → issues SAML assertion → Argo CD's Dex (built-in identity broker) validates → grants access based on groups.

Here's a simple flow diagram (Mermaid syntax — paste into mermaid.live or your blog renderer):

This shows the authentication flow. AWS acts as Identity Provider (IdP), Argo CD/Dex as Service Provider (SP).

3. Detailed Component Diagram – Infrastructure View

Purpose: For the "Architecture and Infrastructure" section. Matches your document's 3.1 overview.

Prerequisites

• A running Kubernetes cluster with Argo CD and (optionally) Argo Workflows installed (preferably via Helm).

• Access to AWS IAM Identity Center with permissions to create SAML applications.

• Argo CD exposed via a domain (e.g., https://argocd.yourdomain.com).

• kubectl access to create secrets and edit ConfigMaps.

• Basic understanding of YAML and Kubernetes resources.

Step-by-Step Implementation

Step 1: Create a Custom SAML 2.0 Application in AWS IAM Identity Center

1. Go to AWS IAM Identity Center → Applications → Add application.

2. Choose Add custom SAML 2.0 application.

3. Set Display name (e.g., "Argo CD SSO").

4. Under Application metadata:

   • Select Manually type metadata values.

   • Application ACS URL: https://argocd.yourdomain.com/api/dex/callback

   • Application SAML audience: https://argocd.yourdomain.com/api/dex/callback

5. (Optional) Set Application start URL: https://argocd.yourdomain.com

6. Download the IAM Identity Center certificate (you'll need it later).

7. Submit and go to Attribute mappings:

   • Add mappings:

     • Subject → ${user:subject} (persistent)

     • groups → ${user:groups}

     • email → ${user:email}

8. Assign users/groups who should access Argo CD.

Note: Use your actual Argo CD domain. The callback URL is critical for Dex.

Step 2: Prepare the Certificate

Base64-encode the downloaded certificate (including -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- lines):

Bash

base64 -w 0 iam-identity-center-cert.pem > encoded-cert.txt

Copy the output for caData.

Step 3: Configure Argo CD (via Helm values or argocd-cm ConfigMap)

Update your Argo CD Helm values (or edit argocd-cm directly):

YAML

configs:
  cm:
    create: true
    url: https://argocd.yourdomain.com
    dex.config: |
      logger:
        level: debug
        format: json
      connectors:
      - type: saml
        id: aws
        name: "AWS IAM Identity Center"
        config:
          ssoURL: "https://portal.sso.<region>.amazonaws.com/saml/assertion/<id>"  # From your SAML app sign-in URL
          caData: "<base64-encoded-cert-from-step-2>"
          entityIssuer: https://argocd.yourdomain.com/api/dex/callback
          redirectURI: https://argocd.yourdomain.com/api/dex/callback
          usernameAttr: email
          emailAttr: email
          groupsAttr: groups

  rbac:
    policy.default: role:readonly
    policy.csv: |
      p, role:readonly, applications, get, /*, allow
      p, role:readonly, certificates, get, *, allow
      p, role:readonly, clusters, get, *, allow
      # ... (add more readonly permissions as needed)

      p, role:admin, applications, create, /*, allow
      p, role:admin, applications, update, /*, allow
      # ... (add admin permissions)

      g, "<your-aws-group-id>", role:admin  # e.g., g, "argocd-admins", role:admin
    scopes: '[groups, email]'

Key Tips:

• ssoURL comes from the SAML app's sign-in URL.

• For group mapping, use the exact group name/ID from AWS (workaround: AWS doesn't officially support groups in SAML, but this works reliably).

• Apply changes and restart Dex pod if needed.

Step 4: Create Kubernetes Secret (for Shared Client Secret if Using Argo Workflows)

Bash

kubectl create secret generic argocd-sso-secret \
  --namespace argocd \
  --from-literal=client-id="https://portal.sso.<region>.amazonaws.com/saml/assertion/<id>" \
  --from-literal=client-secret="some-random-secure-string"  # Or generate one

If Argo Workflows is in a different namespace, recreate the same secret there.

Step 5: Configure Argo Workflows (Optional but Recommended for Unified SSO)

In Argo Workflows Helm values:

YAML

server:
  authModes:
    - sso
    - client  # Optional: keep client for backward compat; can remove later
  sso:
    enabled: true
    issuer: https://argocd.yourdomain.com/api/dex
    clientId:
      name: argocd-sso-secret
      key: client-id
    clientSecret:
      name: argocd-sso-secret
      key: client-secret
    redirectUrl: https://argocd.yourdomain.com/oauth2/callback
    sessionExpiry: 8h

This allows Argo Workflows to use the same Dex instance for SSO.

Step 6: Test the Integration

• Access https://argocd.yourdomain.com

• Click LOGIN VIA SSO

• You should redirect to AWS IAM Identity Center login

• After authentication, return to Argo CD with proper permissions based on your group

Check Dex logs (kubectl logs -n argocd -l app.kubernetes.io/name=argocd-dex-server) for debug info if issues arise.

Troubleshooting Common Issues

• Authentication fails → Verify URLs match exactly (case-sensitive); check certificate encoding.

• Groups not recognized → Confirm group names in AWS and RBAC policy.csv; use debug logging.

• Callback errors → Ensure ACS URL and audience match Dex callback.

• Connectivity → Confirm network policies allow outbound to AWS endpoints.

Best Practices

• Store secrets securely (use external secret managers like AWS Secrets Manager + External Secrets Operator).

• Rotate client secrets periodically.

• Use least-privilege RBAC: Start with readonly default, grant admin only to specific groups.

• Monitor Dex logs and set up alerts for auth failures.

• Test group membership changes in a staging environment.

Conclusion

Integrating AWS IAM Identity Center with Argo CD (and optionally Argo Workflows) via SAML 2.0 brings enterprise-grade authentication to your GitOps workflows. It simplifies onboarding, boosts security, and supports scalable team collaboration — key for CNCF-aligned projects and AWS ecosystems.

By following this guide, you can achieve centralized, secure access in minutes (after initial setup). If you're contributing to open-source or building AWS community projects, this pattern is battle-tested and aligns with modern cloud-native security.

Happy GitOps-ing! If you implement this, share your experiences — feedback helps the community grow.