Overview

Overview

A Cloud Account allows you to store credentials for cloud infrastructure which the Platform Orchestrator needs to connect to at a central place in your Humanitec Organization.

Configured Cloud Accounts can then be referenced in Resource Definitions to connect to cloud resources, removing the need to maintain those credentials for every single Resource Definition. Use the driver_account element to reference a Cloud Account:

apiVersion: entity.humanitec.io/v1b1
kind: Definition
metadata:
  id: my-resource-definition
entity:
  # The driver_account references a Cloud Account configured in the Platform Orchestrator.
  driver_account: my-cloud-account
  ...

See the Account References section below for a flexible way to share Cloud Account references across Resource Definitions.

In order to use a Cloud Account, the Driver being used in the Resource Definition needs to support the respective account type. For example, a “Google Cloud” (GCP) Account can be used by the MariaDB Cloud SQL Driver because that Driver supports gcp in its account types. Likewise, an “Amazon Web Services” (AWS) Account can be used by the AWS Route53 Driver which supports aws in its account types.

You need the Administrator role in the Organization to manage Cloud Accounts.

Dynamic vs static credentials

Each Cloud Account type supports either dynamic or static credentials.

Dynamic credentials are relatively short-lived credentials often created on-the-fly and based on a previously established trust relationship between the involved parties. Because they expire quickly, they pose much less of a risk when breached, and therefore provide superior security when compared to static credentials. They also reduce maintenance effort because they don’t need to be renewed.

Static credentials are relatively long-lived credentials created by some administrative entity and then distributed to its users. Because they can be exploited extensively when breached, they pose a much higher risk than dynamic credentials. Unless valid indefinitely, which is not recommended, they also require maintenance effort for renewing (rotating) them.

Account References

You may use a reference to another Resource Definition in the driver_account instead of a Cloud Account name. Your Resource Definition will then use the Cloud Account of the referenced Resource. Use the .account Placeholder to specify an Account Reference. It is available in the driver_account item only.

  driver_account: ${resources['type.class#id'].account}

This Account Reference will match a config type Resource of class default with the id aws-account:

  driver_account: ${resources['config.default#aws-account'].account}

A common use case is to use different Cloud Accounts for different Environments. To use different accounts, you would normally need to create a separate Resource Definition for each of them, even if the Resource Definition parameters (except the driver_account) are identical. Account referencing lets you use the same Resource Definition for all Environments by referencing an account from another Resource Definition, commonly of type config as shown above, which is Environment specific per its matching criteria.

Go to this extended example to see Account References applied in practice.

AWS