Using environment variables, configuration attributes can be controlled externally by the environment. This section documents the use of environment variables and illustrates possible use cases.
- In the configuration file, environment variables are referenced by one of the following notations:
- ●${ENVVAR}
- ●${ENVVAR:-default}
If variable ENVVAR is defined, its value is taken. It's possible to define an optional default value, in case the variable should not be defined.
Staging
When staging configurations between different environments, certain configuration attributes change. These environment-specific attributes can be controlled using environment variables.
In order to construct a stage-specific entry path using environment variables STAGE and VERSION do the following:
apps: - mappings: entry_path: value: /api/payments-${STAGE}/${VERSION:-head}/
For STAGE=int and VERSION=1.7, this will result in entry path: /api/payments-int/1.7/
If STAGE=dev and VERSION is missing, this will result in entry path: /api/payments-dev/head/
The important part of the Kubernetes deployment configuration for the Microgateway is outlined below:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: microgateway
spec:
replicas: 1
selector:
matchLabels:
app: microgateway-echoserver
template:
metadata:
spec:
initContainers:
- name: configbuilder
image: docker.io/ergon/airlock-microgateway-configbuilder:3.1.0
env:
- name: STAGE
value: int
Shared secrets
Environment variables are handy when the same parameter value must be configured in different containers. Such an example is the use of JWT access tokens, where Airlock IAM issues a JWT and Airlock Microgateway consumes it. Both parties must use the same signature and encryption passphrases. Using environment variables, these secrets can be managed externally. In the following example, variables JWT_SIGNATURE_PASSPHRASE and JWT_ENCRYPTION_PASSPHRASE are used.
apps: - mappings: - entry_path: value: / ... auth: flow: redirect denied_access_url: /auth/ui/app/auth/application/access access: - roles: - authenticated access_token: mandatory: true token_type: signed_and_encrypted expiry_checked: true extraction: mode: header header: regex: pattern: ^Authorization: Bearer (.*)$ signature: method: HS512 passphrase: ${JWT_SIGNATURE_PASSPHRASE} encryption: algorithm: A256GCM passphrase: ${JWT_ENCRYPTION_PASSPHRASE} ...
The important part of the Kubernetes deployment configuration for the Microgateway is outlined below:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: microgateway
spec:
replicas: 1
selector:
matchLabels:
app: microgateway-echoserver
template:
metadata:
spec:
initContainers:
- name: configbuilder
image: docker.io/ergon/airlock-microgateway-configbuilder:3.1.0
env:
- name: JWT_ENCRYPTION_PASSPHRASE
valueFrom:
secretKeyRef:
name: jwt-secret
key: JWT_ENCRYPTION_PASSPHRASE
- name: JWT_SIGNATURE_PASSPHRASE
valueFrom:
secretKeyRef:
name: jwt-secret
key: JWT_SIGNATURE_PASSPHRASE
This use case is configured in the (Github) Airlock Minikube Example.