Container image repo integration

When deploying ADS to a containerized environment, such as Kubernetes or an air-gapped infrastructure, you typically want a self-contained, immutable image where the authorization domain is baked in rather than fetched at runtime. This gives you a versioned deployment artifact: a specific image tag corresponds to a specific policy state, which simplifies rollbacks, auditing, and promotion across environments.

The trade-off is that the authorization domain is frozen at image build time. Whenever policies, attribute connectors, or the attribute dictionary change, a new image must be built and redeployed. For teams that push policy changes frequently, this means your CI/CD pipeline should run stageDeployment and trigger a container build on every commit, in the same way application code changes trigger an application image build.

If you prefer policies to propagate without a redeployment, use the Authorization Hub integration instead, where ADS fetches the domain dynamically from the control plane.

APD can stage the complete ADS deployment build context to disk, so that your CI/CD pipeline can build a container image and push it to your registry. APD is responsible for assembling the artifacts; the actual docker build and docker push (or equivalent buildah / kaniko commands) are performed by your pipeline.

How it works

Running the stageDeployment task assembles all artifacts needed to build a runnable ADS container image and writes them to build/install/deployment/. This directory is the build context you pass to your container build tool.

The task depends on buildAuthzDomain, so compiling policies and generating domain.yaml happens automatically.

./gradlew stageDeployment

Staged output

build/install/deployment/
├── .env.generated          # Generated environment file
└── ads/                    # Docker build context
    ├── Dockerfile
    ├── deployment.yaml     # ADS deployment descriptor
    ├── domain.yaml         # Compiled authorization domain
    ├── axiomatics_ADS.license
    ├── access-decision-service-*.jar
    └── lib/
        ├── *.jar           # Attribute connector JARs
        └── *.whl           # Python PIP dependencies

Pass build/install/deployment/ads/ as the build context to your container build tool.

Important

stageDeployment does not run tests. Always run ./gradlew test as a pipeline step before staging and building the image. Skipping the test step means untested policies can be baked into the published image.

Environment variables

ADS and attribute connectors typically reference runtime configuration, such as PIP URLs, credentials, and hostnames, as environment variables using the ${VAR} syntax. These values are environment-specific and must not be baked into the image.

As part of stageDeployment, APD scans all staged artifacts for environment variable references and generates two files at the root of the staged output, one level above the Docker build context:

• .env.generated : a template listing every variable name found, with empty values. Fill in the values for your target environment before deploying.
• .env.generated.info: a companion file documenting where each variable is referenced, its default value (if any), and ready-to-use snippets for loading the variables on different platforms.

Example .env.generated:

# See .env.generated.info for more information
DB_PASSWORD=
LDAP_URL=
PIP_API_KEY=

The .env.generated.info file includes platform-specific loading instructions. The examples below are just a starting point. Feel free to tailor them to your needs.

Platform	Example command
Docker	docker run --env-file .env <image>
Kubernetes	kubectl create secret generic access-decision-service --from-env-file=.env
Linux	`export $(grep -v '^#' .env

It also contains a ready-to-use Kubernetes Secret manifest with all variables pre-populated, which you can apply directly or incorporate into your Helm chart or Kustomize overlay.

Important

.env.generated contains empty values and is safe to commit to version control as a reference. Never commit a filled-in .env file with real secrets.

Dockerfile

APD ships a default Dockerfile in the distribution. It is staged automatically alongside the other artifacts and requires no additional configuration.

If you need to customize the image (for example, to add CA certificates, change the base image, or adjust JVM options), copy the default Dockerfile from build/install/deployment/ads/ into your project root and edit it there. APD will stage your version instead of the default on subsequent runs.

Building and pushing from a CI/CD pipeline

The stageDeployment task does not build or push images. Wire the staged output into your pipeline's container build step using build/install/deployment/ads/ as the build context. The actual build and push can be done with Docker, Buildah, Kaniko, or any OCI-compatible tool.

See Sample CI/CD pipeline for ready-to-use examples for Jenkins, Azure DevOps, and GitHub Actions.