Cloud Scripting: Secrets Manager

The Cloud Scripting (CS) Secret Manager helps with storing “secrets” - an object that contains a small amount of sensitive data such as API keys, passwords, tokens, and certificates. The secret manager provides convenience while improving security as there is less risk of the secret (and its data) being exposed during the application workflow.

For example, you can use secrets for the following purposes:

pull data from private registries
provide credentials such as SSH keys or passwords
set environment variables

Manage Secrets in Manifest

Secrets can be provided and utilized within the manifest file in the following ways:

secrets

Secrets that are managed by users can be predefined via the “secrets” declaration. The corresponding declaration is performed in advance of the manifest installation. It is similar to “globals”, but values are encrypted and saved in a separate secret manager application. For example:

1
2
3
secrets:
  value1: 1
  value2: 2

setSecrets

This action allows you to set or adjust internal secrets dynamically. For example:

1
2
3
4
5
6
7
8
secrets:
  value1: 1
  value2: 2

onInstall:
- setSecrets:
    value1: 4
    value3: 3

As a result, you’ll have three secrets with the following values after the installation:

1
2
3
${secrets.value1} - 4
${secrets.value2} - 2
${secrets.value3} - 3

Settings

By default, settings provided in the manifest are not encrypted. If you want to save settings in the secret manager and encrypt it, add the “storeType: secret” parameter. For example:

1
2
3
4
5
6
7
settings:
  storeType: secret
  fields:
    - type: string
      inputType: password
      name: pass
      caption: Password

If you don’t want to store settings at all, set the “disposable: true” parameter. As a result, the settings will be available only within the corresponding action and won’t be available for other events. For example:

1
2
3
4
5
6
7
settings:
  disposable: true
  fields:
    - type: string
      inputType: password
      name: pass
      caption: Password

Placeholders

You can use the following placeholders with secrets:

${secrets.(name)} - internal secret of the package
${fn.secret(name, scope)} - a function to obtain any secret of the current user by name and scope
${fn.systemSecret(name)} - a function to obtain a system secret. It is allowed only within the “auth” section and is not logged anywhere. For example, the secret is specified by the admin user to provide access to a private repository
${uniqueName} - unique ID of the application package. It is utilized as a “scope” value for internal secrets of that package

For example: If calling a secret from the same package, you can use just the ${secrets.(name)} placeholder. If you need to get a secret from a different package, you need to obtain the corresponding uniqueName and call fn.secret(name, your_uniqueName).

Also, uniqueName can be used to call API requests for the appropriate package.

Manage Secrets via API

You can use the following API methods to manage secrets:

CreateSecret – creates a new secret
CreateSecrets – creates multiple new secrets
GetSecret – returns the specified secret
ListSecrets – returns a list of all available secrets
ApplySecrets – applies one or more secrets to the specified scope
DeleteSecret – deletes the specified secret

The following private methods are available to admins only:

CreateSystemSecret – creates a system secret that can be utilized by any user in the “auth” section with the fn.SystemSecret placeholder
GetSystemSecret – returns the specified system secrets
DeleteSystemSecret – deletes the specified system secret
Note: The “system” scope for secrets is reserved by the platform and can be managed with the three above-mentioned methods only.
DeleteSecretsByScope – deletes all secrets of the specific scope
GetSecretInternal – returns the specified secret of any user

Refer to the API documentation for detailed methods description.