Secrets

Secrets are secure documents containing access keys, api keys, api secrets or IDs to external systems. They can be created and stored in the ServisBOT system and then referenced by bots or BaaS securely. This is perfect for managing API keys for AWS, or project references for Dialogflow.

Secrets can only be created or deleted. They can also be managed by both the CLI and portal

Secret Properties

Alias The alias is what is used to reference this secure doc in the system.

Type: There are four types of secrets:

  • SecretDoc: a non-scalar array in JSON, better for project specific config
  • A simple string. Good for API keys
  • AWS Cross Account Role
  • Certification

SRN A unique identifier for the ServisBOT system

Managing Secrets in Portal

In portal, a list of all currently created secrets can be seen by navigating to the “Secrets Management Section”. start

There you can see a list of secrets and their creation date.

To create a secret, you will need to gather a couple of things from the external service you are planning on connecting to.

The secret body is what contains your keys. We have some ServisBOT templates available for common secret types.

For AWS

{
  "awsAccessKey": "some-access-key",
  "awsSecretAccessKey": "some-secret-key",
  "awsRegion": "some-aws-region"
}

For Dialogflow V2 Dialogflow generates a key file that can be automatically ingested using the ServisBOT portal. To create a secret using the SLI, the secret value must follow this format. Getting Your Dialogflow Secret

{
  "projectId": "ProjectIDFromDialogflow",
  "privateKey": "ALongDialogflowKey",
  "clientEmail": "ClientEmailFromDialogFlow"
}

For Dialogflow V1

{
  "accessToken": "some-access-token",
  "projectId": "someproject-id"
}

Managing Secrets in the Cli

After logging in to the CLI, you can create a secret by providing either a JSON file or string. There are no prebuilt templates available.

You can also list, delete and describe a secret. Describing a secret does not show you the contents of the document, merely the alias, srn and type.

sb-cli secret create secret.json

To create a secret containing a array of parameters such as a Dialogflow key or AWS secret:

{
    "Name": "ALIAS",
    "Type": "secretdoc",
    "Value": {
        "accessKeyId": "Value",
        "secretAccessKey": "Value",
        "region": "Value"
    }
}

You can also choose to create the secret interactively using the following command, this will guide you through making each type available

sb-cli secret create-interactive

For single API keys or token auth you can change the syntax to make the secret a string.

{
    "Name": "content-cloudfront-key",
    "Type": "secret",
    "Value": "Bearer APIKEYVALUE"
}

Example for basic auth:

{
    "Name": "ALIAS",
    "Type": "secretdoc",
    "Value": {
        "username": "Value",
        "password": "Value"
    }
}

AWS Cross Account Roles

Creation of cross account roles is only supported through the CLI. There are two steps to creating a cross account role:

  • Registering the secret and getting an externalID (for use in AWS).
  • Creating the secret and storing your role’s ARN (Amazon Resource Name).

This can be done interactively with a wizard by running the interactive command:

sb-cli secret create-interactive
  • The command will ask you if you would like to use an existing external id, you should choose this option if you already have an AWS cross account role set up with an external id, and you wish to make a secret containing the role arn and external id.
  • If you do not have have an existing AWS cross account role set up or an external id to use, you should select “No” when prompted to use an existing external id. The next series of prompts will guide you through creating an AWS cross account role with an external id.

Manually Create Secret

1: Register your secret and get an externalID

To register a cross account role secret run the following command where secretname is the name of the secret you are creating.

sb-cli secret create-external-id <secret_name>

You will be given a GUID. Take that guid and complete the following steps:

1) Log into your AWS account and navigate to the IAM console.
2) Create a new IAM role.
3) When prompted for a trusted entity select: "Another AWS account".
4) Enter "616711624162" for the account to trust (Account ID).
5) Check the box to "Require external ID" and enter the GUID given to you in the previous step.
6) Ensure that MFA token is not selected.
7) Select the most appropriate managed policy.
8) Enter a memorable role name and create the role.
9) Copy the provided ARN.

2: Create your secret

Now you can create that secret using the name of the secret you registered in step 1.

sb-cli secret create xrole.json where <secretname> is the name of the secret you registered and <ARN> the value you got from AWS.

Define xrole.json as:

{
  "Name": "awsservicedemosxacct",
  "Organization": "sboperations",
  "Type": "aws-cross-account-role",
  "Value": {
    "ARN": "<ARN>"
  }
}

Using an existing External Id

It’s possible that you already have an AWS cross account role set up with an external id, and you want to create a secret by providing the external id to use in the secret definition. This can be achieved by running sb-cli secret create xrole.json, where xrole.json is defined as:

{
  "Name": "awsservicedemosxacct",
  "Organization": "sboperations",
  "Type": "aws-cross-account-role",
  "Value": {
    "ARN": "<ARN>",
    "ExternalId": "<ExternalId>"
  }
}

This will create a secret containing the provided ARN and ExternalId. Once you’re done delete the xrole.json file from your system.

Certificates

Creation of certification is only supported through the CLI.

This can be done interactively with a wizard by running the interactive command

sb-cli secret create-interactive

Manually Create Secret

While ServisBOT supports certificates in baas calls, creation of certificates is not done by the ServisBOT platform. Create your certificate using the process of choice. e.g. openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem then use either the interactive or manual methods to store the certificate values in our secrets store.

sb-cli secret create certificate.json

Define certification.json as:

{
  "Name": "mycertificatePublic",
  "Organization": "ORGANIZATION",
  "Type": "certificate",
  "Value": {
    "Key": "<Your key here>",
    "Cert": "<Your cert here>"
  }
}