Portal

Secrets

Secret management

The User platform includes a key/secret management service. It provides secure storage and management of secret data - such as passwords, certificates, asymmetric keys, etc.

Using this service can generally improve overall security of your solution in a number of ways:

  • It enables you to use stronger passwords, and keep them unique per instance or per service - which would be difficult to memorize.
  • It eliminates a need to store or share password between multiple users in insecure way (such as emails, instant messengers, etc).
  • It eliminates a need to use a third-party secret management service or application, which would potentially increase the attack surface to your service.
  • Secrets are stored in an encrypted format on the platform.
  • You as a user have control when the secrets are displayed on your screen, so you can ensure nobody else can see them.

While one may consider that storing passwords on the same platform as the resources that use them, and displaying them in plain text on the screen can compromise the overall security, in reality this is a minor concern. Consider the fact that anyone who has access to the account has 100% access to any resource. Even without knowing instance password, such user can easily download the instance image, or mount it to another instance, and still get full access to the instance data.

Object structure

The secrets are stored in containers - so before you create a secret, you need to create or pick a container for that secret. Obviously, a container may store multiple secrets.

Secrets can be of different types. At present, the portal supports passphrase secret type, suitable for storing plain text data such as password. The API backend supports more secret types, including:

  • symmetric - Used for storing byte arrays such as keys suitable for symmetric encryption.
  • public - Used for storing the public key of an asymmetric keypair.
  • private - Used for storing the private key of an asymmetric keypair.
  • certificate - Used for storing cryptographic certificates such as X.509 certificates.

A secret may have an optional expiration date. If set, the secret cannot be retrieved after the expiration date, and will be purged from the database later. If expiration date is not set, the secret will be stored until manually deleted.

Storing instance passwords

When a Linux instance is built, a password will typically be auto-generated for a system user of for such instance. The user will have an opportunity to store that password in the secret storage. To do that, simply click the "Add to my secrets" button when notification screen is displayed.

You will later have an opportunity to see that password, either in the corresponding container called Instance credentials, or on top of the instance console menu when logging in.

You can also store your own passwords in that container - for example, for Windows instances (where passwords are not auto-generated and set manually when instance is initialized), other users (than created during the instance creation) of your Linux instances, or in case you decide to change the password for an existing user later.

In order to do that, just follow the same name convention as the platform uses for auto-generated credentials, storing it on the container called Instance credentials and specifying secret name as {user}@{instance_id}, where user is the username for which password is stored (the username may include an "@" sign where needed), and instance_id is the resource id of the instance. Here are examples of appropriate secret names that platform will recognize:

ubuntu@3f921da7-5c03-41ec-a37a-a7915aaeb020
Administrator@domain@3f921da7-5c03-41ec-a37a-a7915aaeb020

Note that the secret management service is NOT integrated with the credential storage within the instance. That means that if you change the password inside the instance, the corresponding secret will not automatically reflect that.