Access your workloads through the GDC console or the gdcloud CLI.
To sign in to the GDC console or a cluster, work through the following steps:
Console
Open the following URL in a new browser tab to access the Distributed Cloud user interface (UI):
https://GDC_URL
Replace GDC_URL
with the
domain name you use to access Distributed Cloud that the
Infrastructure Operator (IO) provides. When opening any URL for the first
time, Distributed Cloud redirects you to your identity provider
login page if the Infrastructure Operator (IO) configured the page.
For example, the following image signs in to the console UI for an
organization named org-1
:
CLI
You can sign in to any cluster that you have permission to access. The CLI
login process differs between org admin and user clusters. You must only
provide the cluster name and its related kubeconfig
file, and sign in
separately to each cluster.
Before you sign in, ensure you do the following:
- Download the gdcloud CLI binary and install it in your system. For more information, see Download the gdcloud CLI.
- Set up and initialize the gdcloud CLI default configuration. Make sure to set the correct organization URL, which is used to fetch the login config endpoint. For more information, see gdcloud CLI installation.
- Install the authentication plugin
gdcloud-k8s-auth-plugin
. For more information, see gdcloud CLI authentication.
To sign in to an org admin or user cluster, complete the following steps:
- Org admin cluster:
Export the path on where you want to store the org admin kubeconfig file:
export KUBECONFIG=PATH_TO_STORE_KUBECONFIG
Replace PATH_TO_STORE_KUBECONFIG with the path to the directory of where to store the kubeconfig file.
Authenticate your gdcloud CLI instance to sign in. There are two ways to authenticate:
Standard browser login: Use this authentication flow when logging in from a browser.
gdcloud auth login
Secondary device login: Use this authentication flow if your primary device does not have a browser available. This flow starts the login on the primary device with no browser access and continues the login with the secondary device that has browser access.
Initiate the login on your primary device with no browser:
gdcloud auth login --no-browser
The command in the primary device prints another
gdcloud
command that you must run on the secondary device in step c.Repeat step 1 to download the certificate on the secondary device.
Complete the login on the secondary device by entering the command printed on the primary device in step a.
This action opens a browser to sign in to the configured identity provider (IdP). Provide the user and password that you set during the initial gdcloud CLI setup to sign in.
- User cluster:
Authenticate your gdcloud CLI instance to sign in. There are two ways to authenticate:
Standard browser login: Use this authentication flow when logging in from a browser.
gdcloud auth login
Secondary device login: Use this authentication flow if your primary device does not have a browser available. This flow starts the login on the primary device with no browser access and continues the login with the secondary device that has browser access.
Initiate the login on your primary device with no browser:
gdcloud auth login --no-browser
The command in the primary device prints another
gdcloud
command that you must run on the secondary device in step c.Repeat step 1 to download the certificate on the secondary device.
Complete the login on the secondary device by entering the command printed on the primary device in step a.
This action opens a browser to sign in to the configured identity provider (IdP). Provide the user and password that you set during the initial gdcloud CLI setup to sign in.
Export your user identity
kubeconfig
file as a variable:export KUBECONFIG=/tmp/admin-kubeconfig-with-user-identity.yaml
Generate a
kubeconfig
file with your user identity:gdcloud clusters get-credentials CLUSTER_NAME
A
kubeconfig
file is generated with your user identity. The following YAML file shows an example:apiVersion: v1 clusters: - cluster: certificate-authority-data: <REDACTED> server: https://10.200.0.32:443 name: cluster-name contexts: - context: cluster: cluster-name user: cluster-name-anthos-default-user name: cluster-name-cluster-name-anthos-default-user current-context: cluster-name-cluster-name-anthos-default-user kind: Config preferences: {} users: - name: cluster-name-anthos-default-user user: exec: apiVersion: client.authentication.k8s.io/v1 args: - --audience=root-admin command: gdcloud-k8s-auth-plugin env: null installHint: Run 'gdcloud components install gdcloud-k8s-auth-plugin' to use plugin interactiveMode: Never provideClusterInfo: false
To verify that you can access the cluster, sign in with the generated
kubeconfig
file with a user identity:kubectl --kubeconfig /tmp/admin-kubeconfig-with-user-identity.yaml version
Sign out
To sign out of the GDC console, do the following:
Console
Click
Logout in the menu bar.CLI
Log out from the CLI:
gdcloud auth revoke
Session inactivity logout
After fifteen or more minutes of inactivity in a session, the GDC console and gdcloud CLI logs you out. Distributed Cloud considers session inactivity as a period during an open session with no active engagement from you, such as no cursor or keyboard movement. An active session lasts up to twelve hours with user activity.
Console
For session inactivity, the GDC console logs you out. Two minutes before the GDC console logs you out for inactivity, you receive a dialog that cautions you of the logout:
After logging you out for inactivity, you see the following screen:
To log back in to the GDC console, select your identity provider and add your login credentials. If you use a service, such as the monitoring dashboard, and the GDC console logs you out for inactivity, log back in to gain access.
gdcloud
For session inactivity, the gdcloud CLI logs you out. After the gdcloud CLI logs you out, and you attempt to run a command, you receive an authorization error:
Error: error when creating kube client: unable to create k8sclient: Unauthorized
To log back in to GDC, follow the CLI steps in Sign in.
If you log back in to GDC through an org admin
cluster, your kubeconfig file automatically updates. To avoid your kubeconfig
file updating, use the --skip-kubeconfig-update
flag in the
gdcloud auth login
command.
kubectl
The gdcloud CLI expires your kubeconfig files after session
inactivity. If you attempt to run a kubectl
command after inactivity,
you receive an authorization error:
error: You must be logged in to the server (Unauthorized)
To log back in and use your kubeconfig file, follow the CLI steps in Sign in. For every session timeout, you must regenerate your kubeconfig files.