DevOps · K8s · Volleyball · Travel  •  DevOps · K8s · Volleyball · Travel  •  DevOps · K8s · Volleyball · Travel
Explore NY Tech

dcb1eced-9c70-4506-97f1-8523bcbe82f4

July 09, 2026 — LiveStream

image
🛒 Recommended gear on Amazon

Disclosure: some links above are affiliate links — if you buy through them I may earn a small commission at no extra cost to you. Thanks for supporting the channel!

🛒 Today's Picks on Amazon
As an Amazon Associate I earn from qualifying purchases.

Goal

Configure JumpCloud and Google Single Sign-On (SSO) for the Argo CD login page at https://argocd.demo.net/login.

Step 1: Add and Configure the SSO Application

Start by adding the SSO application in JumpCloud and configuring the following parameters:

  • IdP Entity ID: <https://argocd.demo.net/api/dex/callback>
  • SP Entity ID: <https://argocd.demo.net/api/dex/callback>
  • ACS URL: <https://argocd.demo.net/api/dex/callback>
  • IDP URL: <https://sso.jumpcloud.com/saml2/argocd-dev>

Download the metadata, which may include the required certificate or CA data. Encode the contents of the PEM file to base64:

base64 -w 0 < your_certificate.pem > encoded_certificate.txt
image dcb1eced-9c70-4506-97f1-8523bcbe82f4
  • Within the SSO configuration section, there should be an option to download or view the Identity Provider (IdP) metadata.
  • This metadata may include the necessary certificate or CA data.
image-20231207-144545 image-20231207-144709 image-20231208-133709

Due to Dex not supporting Provider-initiated logins, consider disabling App Visibility or acknowledging it as nonfunctional. This information is confirmed by JumpCloud Support, aligning with similar limitations in Okta.

We will have to disable App Visibility or consider it to be nonfunctional since Dex does not support Provider-initiated logins.

JumpCloud Support Response: While comparing the screenshots of your configuration with documentation I was able to find, I found the following in this article (this information is Okta specific, but applies to JumpCloud, as well): "I've disabled App Visibility because Dex doesn't support Provider-initiated login flows." For more context, the above snippet of text is in regards to the displaying of the Argo CD Dex icon within the Okta user portal. Since IdP initiated (Okta/JumpCloud) workflows are not supported, they removed the option for this.

Step 2: Take a Backup and Apply the Changes

Option 1: Version Control Repo Changes

Make required changes in the Bitbucket repo or your version control system.

Option 2: Alternate Method

Create backups of ArgoCD ConfigMaps:

kubectl get cm argocd-cm -o yaml > backup_argocd-cm.yaml
kubectl get cm argocd-rbac-cm -o yaml > backup_argocd-rbac-cm.yaml
cp -rvpf backup_argocd-cm.yaml 1argocd-cm.yaml
cp -rvpf backup_argocd-rbac-cm.yaml 2argocd-rbac-cm.yaml

Open the files 1argocd-cm-yaml and 2argocd-rbac-cm.yaml in a code editor. Save the changes, then apply them:

kubectl apply -f 1argocd-cm-yaml
kubectl apply -f 2argocd-rbac-cm.yaml

1argocd-cm.yaml

apiVersion: v1
kind: ConfigMap
metadata:
 annotations:
 kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app.kubernetes.io/name":"argocd-cm","app.kubernetes.io/part-of":"argocd"},"name":"argocd-cm","namespace":"argocd"}}
 creationTimestamp: "2023-06-14T06:10:13Z"
 labels:
 app.kubernetes.io/name: argocd-cm
 app.kubernetes.io/part-of: argocd
 name: argocd-cm
 namespace: argocd
 resourceVersion: "4000"
 uid: 4702c9ba-8cc9-42e1-b8cb-5041c48efe9e
data:
 url: <<https://argocd.demo.net>>
 dex.config: |
    logger:
      level: debug
    connectors:
      - type: saml
        id: jumpcloud
        name: JumpCloud
        config:
          ssoURL: <<https://sso.jumpcloud.com/saml2/argocd-dev>>
          caData: |
            <PUT OR replace CA DATA HERE>


 usernameAttr: username
 emailAttr: email
 groupsAttr: memberOf

2argocd-rbac-cm.yaml

apiVersion: v1
kind: ConfigMap
metadata:
 name: argocd-rbac-cm
 namespace: argocd
data:
 policy.default: role:readonly
 policy.csv: |
    p, role:org-admin, applications, *, */*, allow
    p, role:org-admin, clusters, get, *, allow
    p, role:org-admin, repositories, get, *, allow
    p, role:org-admin, repositories, create, *, allow
    p, role:org-admin, repositories, update, *, allow
    p, role:org-admin, repositories, delete, *, allow

 # Policy for JumpCloud Group B-team
    g, B-team, role:org-admin

 # Policy for JumpCloud Group DevOps
    g, DevOps, role:org-admin

 # Policy for JumpCloud Group IT Operations
    g, IT Operations, role:org-admin

 # Policy for JumpCloud Group SRE
    g, SRE, role:org-admin

Step 3: Restart Deployment after Creating a New ConfigMap

Ensure the changes take effect by restarting the ArgoCD deployment:

kubectl rollout restart deployment argocd-server -n argocd

Note: It's crucial to consider disabling App Visibility from the JumpCloud portal or acknowledging it as nonfunctional. Dex does not support Provider-initiated logins, and JumpCloud Support has provided guidance on this matter.

Reference: Okta - Argo CD - Declarative GitOps CD for Kubernetes

Note: Disabling App Visibility is crucial due to Dex not supporting Provider-initiated logins.

Disable Admin Login or Change the Admin Password

Once SSO is established in all environments, either change admin passwords or disable admin login by adding a single entry under data in the ArgoCD ConfigMap.

Basic Built-in Roles

  • role:readonly - read-only access to all resources
  • role:admin - unrestricted access to all resources

Default built-in role definitions can be seen in builtin-policy.csv for various resources like Applications, Logs, Accounts, Projects, Clusters, Repositories, Certificates, Applicationsets, and Gpgkeys, with associated actions (Get, Create, Update, Delete, Sync, Override).

Reference: Overview - Argo CD - Declarative GitOps CD for Kubernetes

To disable the admin user, add the following entry under data in the ArgoCD ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  admin.enabled: "false"

Change the Admin Password

Argo CD does not provide a direct command or API to change the admin password. Instead, update the password by creating a Kubernetes secret for the admin user. Follow the provided steps for this process.

1. Connect to the Kubernetes Cluster

Ensure that you are connected to the Kubernetes cluster where Argo CD is installed.

2. Identify the Argo CD Namespace

Identify the namespace where Argo CD is installed. You can use the following command to list all namespaces:

kubectl get namespaces

3. Create a New Admin Password

Generate a new hashed password using the htpasswd command. If you don't have the htpasswd command installed, you can use online tools to generate the hashed password.

htpasswd -nbBC 10 admin your_new_password

Replace your_new_password with the actual password you want to set.

4. Create or Update the Secret

Create or update the argocd-secret in the Argo CD namespace. If the secret does not exist, create it. If it exists, update the existing secret.

kubectl -n argocd create secret generic argocd-secret --from-literal=admin.password=$(htpasswd -nbBC 10 admin your_new_password)

5. Restart the Argo CD Server Pods

To apply the changes, restart the Argo CD server pods. You can do this by deleting the pods, and the deployment controller will create new pods.

kubectl -n argocd delete pod -l app.kubernetes.io/name=argocd-server

6. Verify the Password Change

After the pods restart, verify that the new password is working by logging in with the updated credentials.

argocd login <ARGOCD_SERVER> --username admin --password your_new_password

Replace <ARGOCD_SERVER> with the actual address of your Argo CD server.

Please note that this process involves restarting the Argo CD server pods, which may briefly interrupt service. Make sure to plan for this accordingly, especially in production environments. Additionally, always follow best practices for handling secrets and sensitive information in your environment.

Basic Built-in Roles

  • role:readonly - read-only access to all resources
  • role:admin - unrestricted access to all resources

These default built-in role definitions can be seen in builtin-policy.csv.