Credential

See also: How to manage credentials

In Juju, a credential represents a collection of authentication material (like username & password, or client id & secret key) that is specific to a Juju user and a cloud and allows that user to interact with that cloud.

In Juju a ‘credential’ always refers to authentication material used to access a cloud.

Clouds can have one or more sets of credentials associated with them.

When you create a model in Juju it must always be associated with a cloud/credential pair – the model needs that to create resources on the underlying cloud.

Contents:

Credential name

The credential name is an arbitrary label assigned by a user to a credential when creating the credential on a specific Juju client with the add-credential command.

Because there is no central way to constrain what credential names get used nor oversee what authentication material they represent, different devices can associate the same name with different material, or different names with the same material. This is something to keep in mind, especially in a multi-user context.

Credential authentication type

Each credential is characterised by an authentication type. For machine clouds, the authentication type decides what cloud authentication material you will need to provide to Juju in order to be able to connect to a given cloud. The list of supported authentication types, and their definition, differ from cloud to cloud; check the Reference doc for your cloud to find out what they are.

See more: List of supported clouds > <your cloud> > Credentials

Client vs. controller credential

Juju credentials can be created for either the Juju client or the Juju controller or both – where a client credential (previously known as a ‘local credential’) denotes a credential that the client is aware of and a controller credential (previously known as a ‘remote credential’) denotes a credential that a controller is aware of. When you bootstrap a controller and use a client credential, this credential gets automatically uploaded to the controller, so it becomes a controller credential also.

The set of client credentials and controller credentials can end up being the same. However, they don’t have to.

File credentials.yaml

The credentials.yaml file is the file in your Juju installation where Juju stores your cloud credential definitions. This includes definitions that Juju has created for your (e.g., for the built-in localhost (LXD) and microk8s clouds) as well as any definitions you have provided yourself, either interactively (by typing juju add-credential... and then following the interactive prompts) or manually (either via a YAML file or via environment variables).


Expand to view an example of five credentials being stored against four clouds
credentials:
  aws:
    <credential-name>:
      auth-type: access-key
      access-key: <key>
      secret-key: <key>
  azure:
    <credential-name>:
      auth-type: service-principal-secret
      application-id: <uuid>
      application-password: <password>
      subscription-id: <uuid>
  lxd:
    <credential-a>:
      auth-type: interactive
      trust-password: <password>
    <credential-b>:
      auth-type: interactive
      trust-password: <password>
  google:
    <credential-name>:
      auth-type: oauth2
      project-id: <project-id>
      private-key: <private-key>
      client-email: <email>
      client-id: <client-id>

Last updated 22 days ago. Help improve this document in the forum.