Environment variables

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

…Show more…Show less

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}
                ...

…Show more…Show less

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

…Show more…Show less

This use case is configured in the (Github) Airlock Minikube Example.