Author: @aat
This feature will support registration and retrieval of secrets and configuration keys for FTL modules, and tooling for the creation, retrieval, and enumeration of same.
Most resources in FTL are defined declaratively in end-user code, then FTL itself takes care of provisioning them. Configuration and secrets are distinct however, in that declaring them simply specifies that they should exist, but the creation of the secret or configuration value itself must occur out of band. This constraint necessitates a design that is somewhat different from anything else in FTL.
In order to support bootstrapping configuration and secret defaults when cloning an FTL project, we'll introduce a new configuration file ftl-project.toml
that will be searched for using similar semantics to that of .gitignore
files. Typically there would be a single file per repository. This file will contain a mapping from configuration and secret keys to URIs defining where the value is stored. In the inline://
case, the value will be stored directly in the TOML file. The format is described in detail below.
Sensitive secrets that should not be persisted in Git will be stored in the system keychain. Finally, in production, configuration will be loaded from the FTL database, and secrets may be loaded from an existing cloud secrets manager such as ASM.
These requirements imply that configuration and secrets will need a layered approach, where FTL is able to store and retrieve keys from different locations. Each configuration/secret store will have its own identifier, with a default storage provider selected based on deployment environment.
Here's a hypothetical interaction with the proposed FTL CLI using these different providers:
ftl-project.toml
formatHere's an example of the configuration file that might be created by the commands above:
A group of commands will be added under ftl config
:
And ftl secret
:
ftl secret set
will prompt for a secret value. Note that there is no mechanism to retrieve secrets. This is deliberate to reduce the chance of secrets leaking, but may be revisited once FTL gets RBAC.
We'll add a new database table for configuration values:
Two new gRPC services will be created that the Controller will implement:
ConfigService
will manage configuration using the available configuration providers.SecretService
will manage secrets using the available secret providers.Only ConfigService
is shown below, as SecretService
is identical except for identifier names.
The Runner will be modified such that when a Deploy()
request is received, the Runner will:
Retrieve all secrets and configuration values for the module being deployed, by issuing an EnumerateConfig()
and an EnumerateSecrets()
call to the Controller, respectively.
Encode each configuration value into an environment variable for the module being executed, in the following format:
Encode each secret into an environment variable for the module being executed, in the following format:
Note: the Go and Kotlin runtimes are already retrieving configuration and secret values from environment variables.
The API currently looks like this:
Each runtime's schema extraction code will be updated to recognise these declarations, and create entries in the schema (described below).
Configuration and secrets are privately module scoped, like all other resources. We will add module-level stanzas for each type, with something like the following syntax:
eg.
In addition we will add reference tracking to verbs, though perhaps in a followup change.