Authentication basics

Before you can interact with Cloud de Confiance by S3NS APIs and services, you need to prove that you are who you say you are. This process of proving your identity is known as authentication.

To authenticate to Cloud de Confiance by S3NS, you must provide credentials as evidence of your identity. For example, to use a service, you might authenticate using credentials such as a password and a one-time code.

Cloud de Confiance by S3NS refers to authenticated users as principals. When you attempt to access a resource such as a Cloud de Confiance by S3NS project or storage bucket, Cloud de Confiance by S3NS checks what level of access your principal has to the requested resource. This process is called authorization, and is handled by a system called Identity and Access Management (IAM).

These same concepts apply to code performing automated tasks on your behalf, which are known as workloads. A workload must provide credentials to prove its identity and authenticate as a principal, after which Cloud de Confiance by S3NS can determine what level of access the workload has to the resources it has requested.

Principal types

There are different types of principals that you can authenticate as. You might even use different principal types at different stages of a task, or across different development environments.

The primary principal types and the credentials they require to authenticate include the following:

  • User accounts: These are Google Accounts that are for humans to do interactive work, such as incidental administrative tasks, non-programmatic configuration of Cloud de Confiance by S3NS services, testing, experimenting, and observability.

    You authenticate as a user account with user credentials, such as a password and one-time code.

  • Service accounts: These are accounts internal to Cloud de Confiance by S3NS that workloads can use to access services or resources. You typically don't authenticate as a service account directly. Instead, you attach a service account to a resource such as a Compute Engine VM, or use service account impersonation.

    For most scenarios, we recommend using short-lived service account credentials to authenticate a service account.

  • Federated identities: These are identities that reference user or service accounts in an external identity provider. There are two types of federated identities supported by Cloud de Confiance by S3NS, which have similar names:

To learn more about these and other supported principal types in Cloud de Confiance by S3NS, see Principal types.

Configure your Cloud de Confiance by S3NS organization for authentication

When setting up authentication for your Cloud de Confiance by S3NS organization, you might need to integrate existing systems and workflows into Cloud de Confiance by S3NS:

  • If you have an existing identity provider that you want to use, you need to set up Workforce Identity Federation.

  • If you have workloads running outside of Cloud de Confiance by S3NS that need access to Cloud de Confiance by S3NS resources, you need to set up Workload Identity Federation.

We recommend that you also do the following to help secure your Cloud de Confiance by S3NS environment:

Authenticate humans and workloads

How you authenticate to Cloud de Confiance by S3NS depends on the APIs and services that you're using, and the way in which you interact with those APIs and services.

Authenticate humans

When performing manual, interactive work such as incidental administrative tasks, setting up resources, changing configurations, experimenting, and browsing logs, you use your user account's credentials to authenticate.

Console

For interactive work in the Cloud de Confiance console, you authenticate by signing in to the web interface with your user credentials.

Go to the Cloud de Confiance console

The same credentials for your Cloud de Confiance console session are used for Cloud Shell, where you can access the gcloud CLI.

gcloud

After you install the gcloud CLI on your local device, you can use your user credentials to authenticate to Cloud de Confiance by S3NS by running the following command in your terminal:

gcloud auth login

After you authenticate, subsequent gcloud commands use the signed-in principal to make their requests.

For authenticating with Workforce Identity Federation credentials, Workload Identity Federation credentials, or service account keys, see Authenticate for using the gcloud CLI.

Authenticate workloads

Whether you're developing and running code on your local device, in Cloud de Confiance by S3NS, on-premises, or in another cloud, the most flexible and portable way to authenticate your workload is to provide credentials through a mechanism called Application Default Credentials (ADC).

Libraries that implement ADC (such as the Cloud de Confiance by S3NS client libraries) check known locations in the environment they're run in for credentials. This means that, if you change where your code runs, you don't need to change the code itself—only the credentials that are used for that environment.

For example, when developing locally, you can set your environment so that ADC makes use of your user credentials for authentication. When your code is ready for production, you can deploy it unchanged to a Compute Engine VM instance, and set the environment to use short-lived service account credentials to authenticate instead.

You can't use ADC to authenticate in the following scenarios:

  • When authenticating the gcloud CLI.

  • When using an API key. API keys can only be used with specific APIs.

To learn how to set up ADC for specific environments, see Set up Application Default Credentials.

What's next