Environment variables

Axiomatics Policy DevOps (APD) supports environment variables in policies, attribute connectors, test data, and other configurations. You can also define default values for variables where needed.

The following examples show variable substitution with and without default values:

${PIP_URL}
${PIP_URL:-http://ldap.myorganization.com}

You can use variables in the YAML files within your authorization domain. Environment variables are particularly useful for configuration that varies across environments (such as Dev and Prod). For instance, to set the logging level to INFO by default but allow enabling debug level in the Dev environment, you can use the following in your deployment.yaml:

deployment.yaml

...
logging:
  level: ${LOGLEVEL:-INFO}
...

Variable substitution also works in attribute connector configuration files. This is especially useful for secrets such as passwords and for URLs that differ between environments:

src/authorizationDomain/attributeConnectors/ldapConnector.yaml

className: com.axiomatics.acs.plugin.pips.ldap.LdapPipModule
providedAttributes:
  - attributeName: user.role
configuration:
  host: ${LDAP_HOST:-ldap.corp.example.com}
  port: ${LDAP_PORT:-636}
  bindUser: ${LDAP_BIND_USER}
  bindPassword: ${LDAP_BIND_PASSWORD}

In this example LDAP_HOST and LDAP_PORT have default values suitable for local development. LDAP_BIND_USER and LDAP_BIND_PASSWORD have no defaults and must be supplied as environment variables — they should never be committed to source control.

Defining variables

You can define variable values either directly in your build.gradle file (suitable for non-sensitive data) or by inheriting them from the source environment (preferable for sensitive data).

• Running unit tests

  Define variables within the test {} block in your build.gradle file:

  test {
      environment "LDAP_PIP_URL", "http://ldap-dev.myorg.com"
  }

• Running tests against a specific ADS instance

  Define variables within the task definition in your build.gradle file:

  task test_DevEnv(type: Test) {
      group "verification"
      environment "ALFA_TEST_REMOTE_URL", "http://127.0.0.1:53491/authorize"
      environment "ALFA_TEST_REMOTE_USER", "pdp-user"
      environment "ALFA_TEST_REMOTE_PASSWORD", "secret"
  }

• Running a local ADS instance

  Define variables when starting a local ADS instance:

  runAds {
   environment "LOGLEVEL", "debug"
  }

Accessing and passing environment variables

This section describes how to retrieve environment variables from the source environment and pass them to Gradle tasks.

To access the value of an environment variable from the source environment (your local machine or build server) when executing a Gradle task, use the following:

providers.environmentVariable("LDAP_PIP_PASSWORD").get()

To pass an environment variable from the source environment to a task, you can use the following in your build.gradle file:

build.gradle

 def  KEY_PIP_LDAP_PASSWORD = 'PIP_LDAP_PASSWORD'
 test {
    environment KEY_PIP_LDAP_PASSWORD, providers.environmentVariable(KEY_PIP_LDAP_PASSWORD).get()
 }

note

The source environment can be your local IDE or a Jenkins build server. Using environment variables allows you to securely store sensitive credentials in the Jenkins Secrets store.

You can also specify variables directly from the command line using standard methods:

• Linux

  $ USER_WITH_ROLE_A=Bob PIP_PASSWORD=abc123 PIP_URL=http://ldapprod.acme.com ./gradlew test_ProductionEnv

• Windows

  set USER_WITH_ROLE_A=Bob
  set PIP_PASSWORD=abc123
  set PIP_URL=http://ldapprod.acme.com
  gradlew test_ProductionEnv

.env file generation

Tasks createEnvFile and stageDeployment will generate an .env file in /build/.env.generated and build/install/deployment/.env.generated respectively. This file can serve as a template for Operations of ADS.