paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 38 Packages Projects Releases Wiki Activity

Merge pull request #2741 from spotify/rugvip/short

Browse Source 
config-loader: add support for new short-form secret syntax
This commit is contained in:
Patrik Oldsberg
2020-10-05 13:30:04 +02:00
committed by GitHub
parent 86e5c629de eaf169c07a
commit 34eb3a13c8
19 changed files with 188 additions and 179 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/auth/auth-backend-classes.md
+6 -11
View File
@@ -67,26 +67,21 @@ auth:
google:
development:
clientId:
$secret:
env: AUTH_GOOGLE_CLIENT_ID
$env: AUTH_GOOGLE_CLIENT_ID
clientSecret:
$secret:
env: AUTH_GOOGLE_CLIENT_SECRET
$env: AUTH_GOOGLE_CLIENT_SECRET
github:
development:
clientId:
$secret:
env: AUTH_GITHUB_CLIENT_ID
$env: AUTH_GITHUB_CLIENT_ID
clientSecret:
$secret:
env: AUTH_GITHUB_CLIENT_SECRET
$env: AUTH_GITHUB_CLIENT_SECRET
enterpriseInstanceUrl:
$secret:
env: AUTH_GITHUB_ENTERPRISE_INSTANCE_URL
$env: AUTH_GITHUB_ENTERPRISE_INSTANCE_URL
gitlab:
development:
clientId:
$secret:
$env:
...
```
docs/conf/index.md
+2 -1
View File
@@ -18,7 +18,8 @@ allowing for customization.
Configuration is stored in `app-config.yaml` files, with support for suffixes
such as `app-config.production.yaml` to override values for specific
environments. The configuration files themselves contain plain YAML, but with
support for loading in secrets from various sources using a `$secret` key.
support for loading in secrets from various sources using for example `$env` and
`$file` keys.
It is also possible to supply configuration through environment variables, for
example `APP_CONFIG_app_baseUrl=https://staging.example.com`. However these
docs/conf/writing.md
+14 -19
View File
@@ -90,18 +90,17 @@ order:
## Secrets
Secrets are supported via a special `$secret` key, which in turn provides a
number of different ways to read in secrets. To load a configuration value as a
secret, supply an object with a single `$secret` key, and within that supply an
object that describes how the secret is loaded. For example, the following will
read the config key `backend.mySecretKey` from the environment variable
`MY_SECRET_KEY`:
Secrets are supported via a special secret keys that are prefixed with `$`,
which in turn provides a number of different ways to read in secrets. To load a
configuration value as a secret, supply an object with one of the special secret
keys, for example `$env` or `$file`. A full list of supported secret keys can be
found below. For example, the following will read the config key
`backend.mySecretKey` from the environment variable `MY_SECRET_KEY`:
```yaml
backend:
mySecretKey:
$secret:
env: MY_SECRET_KEY
$env: MY_SECRET_KEY
```
With the above configuration, calling `config.getString('backend.mySecretKey')`
@@ -123,8 +122,7 @@ This reads a secret from an environment variable. For example, the following
config loads the secret from the `MY_SECRET` env var.
```yaml
$secret:
env: MY_SECRET
$env: MY_SECRET
```
### File Secrets
@@ -135,22 +133,19 @@ following reads the contents of `my-secret.txt` relative to the config file
itself:
```yaml
$secret:
file: ./my-secret.txt
$file: ./my-secret.txt
```
### Data File Secrets
This reads secrets from a path within a JSON-like data file. The file path
behaves similar to file secrets, but in addition a `path` is used to point to a
specific value inside the file. Supported file extensions are `.json`, `.yaml`,
and `.yml`. For example, the following would read out `my-secret-key` from
`my-secrets.json`:
behaves similar to file secrets, but with the addition of a url fragment that is
used to point to a specific value inside the file. Supported file extensions are
`.json`, `.yaml`, and `.yml`. For example, the following would read out
`my-secret-key` from `my-secrets.json`:
```yaml
$secret:
data: ./my-secrets.json
path: deployment.key
$data: ./my-secrets.json#deployment.key
# my-secrets.json
{
docs/features/software-catalog/configuration.md
+6 -12
View File
@@ -23,32 +23,26 @@ integrations:
github:
- host: github.com
token:
$secret:
env: GITHUB_TOKEN
$env: GITHUB_TOKEN
- host: ghe.example.net
apiBaseUrl: https://ghe.example.net/api/v3
rawBaseUrl: https://ghe.example.net/raw
token:
$secret:
env: GHE_TOKEN
$env: GHE_TOKEN
gitlab:
- host: gitlab.com
token:
$secret:
env: GITLAB_TOKEN
$env: GITLAB_TOKEN
bitbucket:
- host: bitbucket.org
username:
$secret:
env: BITBUCKET_USERNAME
$env: BITBUCKET_USERNAME
appPassword:
$secret:
env: BITBUCKET_APP_PASSWORD
$env: BITBUCKET_APP_PASSWORD
azure:
- host: dev.azure.com
token:
$secret:
env: AZURE_TOKEN
$env: AZURE_TOKEN
```
Each key under `integrations` is a separate configuration for each external
docs/features/software-templates/installation.md
+3 -6
View File
@@ -232,15 +232,13 @@ instance:
scaffolder:
github:
token:
$secret:
env: GITHUB_ACCESS_TOKEN
$env: GITHUB_ACCESS_TOKEN
visibility: public # or 'internal' or 'private'
gitlab:
api:
baseUrl: https://gitlab.com
token:
$secret:
env: SCAFFOLDER_GITLAB_PRIVATE_TOKEN
$env: SCAFFOLDER_GITLAB_PRIVATE_TOKEN
```
#### Azure DevOps
@@ -257,8 +255,7 @@ scaffolder:
baseUrl: https://dev.azure.com/{your-organization}
api:
token:
$secret:
env: AZURE_PRIVATE_TOKEN
$env: AZURE_PRIVATE_TOKEN
```
### Running the Backend
docs/plugins/proxying.md
+1 -2
View File
@@ -41,8 +41,7 @@ proxy:
target: http://larger.example.com:8080/svc.v1
headers:
Authorization:
$secret:
env: EXAMPLE_AUTH_HEADER
$env: EXAMPLE_AUTH_HEADER
```
Each key under the proxy configuration entry is a route to match, below the
docs/tutorials/quickstart-app-auth.md
+3 -6
View File
@@ -72,15 +72,12 @@ auth:
github:
development:
clientId:
$secret:
env: AUTH_GITHUB_CLIENT_ID
$env: AUTH_GITHUB_CLIENT_ID
clientSecret:
$secret:
env: AUTH_GITHUB_CLIENT_SECRET
$env: AUTH_GITHUB_CLIENT_SECRET
## uncomment the following three lines if using enterprise
# enterpriseInstanceUrl:
# $secret:
# env: AUTH_GITHUB_ENTERPRISE_INSTANCE_URL
# $env: AUTH_GITHUB_ENTERPRISE_INSTANCE_URL
```
2. Set environment variables in whatever fashion is easiest for you. I chose to