Skip to content

Connecting to your cluster

Access to your cluster is self-service through the Customer Portal. Once your cluster is provisioned and your federated identity has been granted access, you issue your own kubeconfig from the portal; there is no credential file to wait for, and no shared team credential to pass around.

Getting access

The users named in your order are granted access when the cluster is provisioned. After that, your customer admin manages access directly in the portal: adding a user takes effect immediately, and removing one also revokes every kubeconfig they hold on the cluster.

Sign in to the portal with your federated identity (SWAMID), open your cluster, and issue a kubeconfig under My credentials. Each credential is personal: it is issued to your identity, labeled so you can tell your credentials apart (for example laptop and ci), and can be rotated or revoked independently. The kubeconfig is shown exactly once at issue time, so download it right away.

See Tenant Kubernetes clusters for the full portal workflow: issuing, rotating, and revoking credentials, and managing cluster users.

First connection

Point kubectl at the downloaded kubeconfig and confirm access:

export KUBECONFIG=/path/to/your-cluster.kubeconfig
kubectl config get-contexts
kubectl get applications -n argocd

First Argo CD sign-in

Argo CD is available at the canonical hostname for your cluster:

https://argocd.<cluster-slug>.k8s-prod.sunetvdc.se

Replace <cluster-slug> with the slug shown in the portal. Use this canonical address unless SUNET has confirmed that your optional Argo CD DNS alias is active.

On a newly provisioned cluster, get the generated initial password with your portal-issued kubeconfig:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 --decode; echo

Sign in at the Argo CD address with username admin and that password. The initial password is a bootstrap credential: after you change the admin password, it is no longer the current password.

Argo CD access is shared administration

Today, every person who can issue a kubeconfig for the cluster has full administrator access to Argo CD. They can read Secrets and change configuration in the argocd namespace, including the shared admin password and Argo CD user permissions. Keep the admin password in your organization's password manager, change it after the first sign-in, and give kubeconfig access only to people you trust with this responsibility.

Portal roles do not change these Argo CD permissions: customer admin lets you manage cluster users in the portal, while every portal user with a kubeconfig has the same current Argo CD administrator access.

Customer changes can affect SUNET-managed components

The permissions also let you change or delete Argo CD Applications and supporting components that SUNET manages, such as Argo CD itself and Sealed Secrets. Doing so can disrupt cluster functionality. Problems caused by customer changes to these components are not counted as a SUNET service-level-agreement failure. Do not change or delete them unless directed by SUNET or as part of an agreed support activity.

Creating Argo CD local accounts

Without single sign-on, Argo CD local accounts are the way to give people separate web-interface logins. Creating an account has three steps:

  1. Enable the account in argocd-cm. For example, add the following under data to create alice as a login-capable account:
accounts.alice: login

You can make the initial change with:

kubectl -n argocd edit configmap argocd-cm
  1. Grant the account a role in argocd-rbac-cm. For a customer administrator, add this data entry. The ConfigMap has no customer policy by default, so create policy.csv if it is not already present:
data:
  policy.csv: |
    g, alice, role:admin

Make the initial policy change with:

kubectl -n argocd edit configmap argocd-rbac-cm
  1. Sign in as admin with the Argo CD CLI and set the account password:
argocd account update-password --account alice

The CLI prompts for the current administrator password and the new account password. Install the Argo CD CLI and log in to your cluster's Argo CD hostname first.

The argocd-cm and argocd-rbac-cm ConfigMaps are managed through GitOps. Record account and policy changes in the Git source that manages your Argo CD installation; an edit made only with kubectl can be reverted by Argo CD self-healing. Use a separate local account for each person rather than sharing the bootstrap admin account.

What your account can do

Your credential is scoped via RBAC to the argocd namespace, where you manage Argo CD applications and administration. Other namespaces and cluster-wide resources remain isolated for security.

This means you do not create workloads directly with kubectl apply into arbitrary namespaces. Instead you commit manifests to your Git repository and let ArgoCD deploy them, including into other namespaces. See GitOps with ArgoCD for how that works.