Abitrary Credentials and Parameters

[carolynvs]

I have a use case for credentials that doesn't work well with CNAB yet. The Porter Operator bundle needs to create Kubernetes secrets for arbitrary data, whatever credentials the the plugin configured in config.toml needs.

For example, if I'm using the operator with the azure plugin, I need to add a bunch of AZURE_* environment variables for porter to use to authenticate to storage. However since nothing about the Porter Operator bundle is specific to azure, I don't want to define credentials for each azure auth value. If someone comes up with an aws plugin, they should be able to use the same bundle and pass in whatever credentials it needs too.

If we had polymorphic bundle dependencies, that would be a great way to solve this. Where the porter operator bundle could depend upon a configuration bundle that could be satisfied by an azure plugin bundle that collects azure credentials, or one that works for aws, etc. But we aren't going to have that for a while, and I think the following suggestion may be useful for other scenarios, especially if we do the mixins as bundles feature.

What I would like to be able to do is pass in arbitrary values as credentials or parameters. My bundle can define a credential to hold a set of values:

credentials:
  - name: env-secrets
    description: Any environment variables used by the config file
    group:
      envPrefix: ENV_SECRET_ # use either envPrefix or dir depending if you want env vars or files
      dir: /cnab/app/env-secrets/

The client can create a credential set that sets the values they want to pass into the bundle when it's installed. They can specify how it should be provided (env vars, secrets, etc), what to call it once it's in the bundle, and where to get the data from.

In the example credential set below, the user is injecting environment variables using values from a secret store.

name: azure-plugin-creds
credentials:
- name: env-secrets
  sourceGroup:
    secret:
      AZURE_STORAGE_CONNECTION_STRING: dev-azure-storage-connStr
      AZURE_CLIENT_ID: dev-azure-client-id
      AZURE_CLIENT_SECRET: dev-azure-client-secret
      AZURE_TENANT_ID: dev-azure-tenant-id

They would install the bundle like normal, porter install -r ghcr.io/getporter/porter-operator:canary -c azure-plugin-secrets.

Porter would then resolve those secrets and inject them as environment variables into the invocation image, all prefixed with ENV_SECRET_, e.g. ENV_SECRET_AZURE_TENANT_ID. From the template side, they can access the values using bundle.credentials.env-secrets where the value of env-secrets is a map of injected credential names to a credential struct containing its value.

env-secrets:
  AZURE_TENANT_ID:
    name: AZURE_TENANT_ID
    env: ENV_SECRET_AZURE_TENANT_ID
    value: abc123
  AZURE_CLIENT_ID:
    name: AZURE_CLIENT_ID
    env: ENV_SECRET_AZURE_CLIENT_ID
    value: def456

Users can also access this information directly from environment variables or in a directory where all the arbitrary files were injected by Porter.

For my particular use case, I'm going to make a new mixin for handlebars that lets me template out a kubernetes secret using this injected data. But this issue just describes how to get arbitrary secrets into the bundle securely.