How to distribute site-specific secrets and configurations

In the Avassa system, an application specification defines the container structure and associated application-specific configuration and secrets. You want to aim for keeping one application specification per application. The reason is to simplify configuration management. When you start deploying applications across 100s or 1000s of sites, it will make your life easier if you can keep as few application specifications as possible.

The challenge is that not all sites are the same and in many cases, each site may require a variation in application configuration and associated secrets.

The recommendation is therefore to store common configuration inline in the application specification and break out site-specific configuration and secrets into the Avassa built-in secrets manager; Strongbox. Create one specific vault per site to manage the specifics of that site, and let the application specification reference that.

But now the question becomes, how do you declare this in your application specification?

As an example, let’s assume you have three sites:

• new-york
• london
• stockholm

Create three vaults that are distributed to one site each, the naming convention in the example is config-<site-name>. For the New York site:

supctl create strongbox vaults <<EOF
name: config-new-york
distribute:
  sites: 
    - new-york
EOF

Now in your application specification you use the ${SYS_SITE} variable that will resolve to the site’s name on deployment

name: my-app
services:
  - name: my-svc
    variables:
      - name: username
        value-from-vault-secret:
          vault: config-${SYS_SITE}
          secret: credentials
          key: username

When deployed to the New York site, the username variable will be read from the config-new-york vault.

In the example above we used a mapping to a variable, the same technique can also be used for volume mounts and DNS.

In this short article, we showed a useful design pattern to use variables in the application specification that expands to separate vaults per site. That way, you can keep the application specifications simple and limited to just one per application. Site-specifics are isolated into separate vaults that the Avassa system makes sure get distributed to the corresponding site.