Gravitee Access Management

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2ms (2 vCPU / 8 GiB RAM) is the recommended starting size. The two JVM services and PostgreSQL fit comfortably. Choose Standard_B4ms for heavier production use.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network, and 443/tcp and 8443/tcp from your users.

The image serves a self-signed TLS certificate generated per VM. For production, install your own certificate or front the VM with your own domain and certificate.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Gravitee Access Management by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22), HTTPS (443) and custom 8443.

Review the dedicated data disk on the Disks tab, then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:gravitee-access-management:default:latest
az vm create \
  --resource-group <your-rg> \
  --name gravitee-am \
  --image sac1647283583153:gravitee-access-management:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name gravitee-am --port 443 --priority 1010
az vm open-port --resource-group <your-rg> --name gravitee-am --port 8443 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the stack is running

The Gravitee AM containers run under Docker as a Compose stack managed by a single systemd unit. On first boot, the stack rotates every secret, recreates itself on a fresh PostgreSQL database and seeds a per-VM admin console account. The multi-container stack can take a couple of minutes to become fully healthy after the VM is created.

Confirm that both services are active:

systemctl is-active gravitee-am.service docker.service

Both report active. List the running containers:

sudo docker compose -f /var/lib/gravitee-am/docker-compose.yml ps

Step 5 - Retrieve your per-VM admin credentials

First boot writes a unique console admin password to a root-only file. Read it with sudo:

sudo cat /root/gravitee-am-credentials.txt

Step 6 - Confirm the console is reachable over TLS

The management console is served over HTTPS on port 443. The certificate is self-signed per VM, so the command uses -k:

curl -sk -o /dev/null -w 'console: HTTP %{http_code}\n' https://localhost/

It returns HTTP 200.

Step 7 - Confirm the stock default credential is rejected

This image never ships the Gravitee admin/adminadmin default. Confirm that only your per-VM password authenticates against the management API. In the commands below, replace <GRAVITEE_ADMIN_PASSWORD> with the per-VM password from the credentials file:

echo -n 'per-VM admin password accepted: ' curl -sk -o /dev/null -w 'HTTP %{http_code}\n' -X POST -u 'admin:<GRAVITEE_ADMIN_PASSWORD>' https://localhost/management/auth/token
echo -n 'stock admin/adminadmin default: ' curl -sk -o /dev/null -w 'HTTP %{http_code}\n' -X POST -u 'admin:adminadmin' https://localhost/management/auth/token

The per-VM password returns HTTP 200; admin/adminadmin returns HTTP 401.

Step 8 - Issue and validate a real OAuth2 token

This self-contained example runs end to end. It authenticates to the management API, creates a security domain and a client_credentials application, and waits for the gateway to publish the domain. It then requests and validates a real access token:

ADMIN_PASS='<GRAVITEE_ADMIN_PASSWORD>' MGMT=https://localhost/management GW=https://localhost:8443
TOKEN=$(curl -sk -X POST -u "admin:${ADMIN_PASS}" "$MGMT/auth/token" | jq -r .access_token) if [ -z "$TOKEN" ] || [ "$TOKEN" = "null" ]; then echo "Sign in first with your per-VM admin password (Step 5), then re-run this step." exit 0 fi OE="$MGMT/organizations/DEFAULT/environments/DEFAULT"
DID=$(curl -sk -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"quickstart","description":"quickstart demo","dataPlaneId":"default"}' "$OE/domains" | jq -r .id)
curl -sk -X PATCH -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"enabled":true}' "$OE/domains/$DID" -o /dev/null
DPATH=$(curl -sk -H "Authorization: Bearer $TOKEN" "$OE/domains/$DID" | jq -r .path)
APP=$(curl -sk -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"quickstart-service","type":"SERVICE"}' "$OE/domains/$DID/applications")
CID=$(echo "$APP" | jq -r .settings.oauth.clientId)
CSEC=$(echo "$APP" | jq -r .settings.oauth.clientSecret) for i in $(seq 1 40); do [ "$(curl -sk -o /dev/null -w '%{http_code}' "${GW}${DPATH}/oidc/.well-known/openid-configuration")" = "200" ] && break sleep 3 done curl -sk -X POST -u "${CID}:${CSEC}" -d grant_type=client_credentials "${GW}${DPATH}/oauth/token" \
  | jq '{token_type, expires_in, access_token: (.access_token[0:40] + "...")}'

The gateway returns a signed JWT access token with token_type: bearer. You can also call the introspection endpoint to confirm that the token is active.

Step 9 - Sign in to the management console

Browse to https://<vm-public-ip>/. Accept the self-signed certificate warning, or install your own certificate. Sign in as admin with the password from Step 5.

The console opens on your security domain's dashboard, which shows users and registered applications at a glance.

Open Applications to see your registered OAuth2/OIDC clients and create new ones. You can manage their grant types, scopes, redirect URIs and client credentials there.

Step 10 - Confirm data lives on the dedicated disk

The PostgreSQL database, the Compose project and the per-VM TLS certificate all live on a dedicated 40 GiB Azure data disk mounted at /var/lib/gravitee-am:

df -h /var/lib/gravitee-am

Creating your first application

In the console, create a security domain (Settings, then General). Under Applications, click Create application and pick the type that matches your client:

• Web: a server-side app using the authorization-code flow
• Single-Page App: a browser app with PKCE
• Native: a mobile app
• Service: machine-to-machine access (client_credentials)

Configure the application's redirect URIs, grant types and scopes. Then use the OpenID Connect discovery document at https://<vm>:8443/<domain-path>/oidc/.well-known/openid-configuration to wire up your application.

Maintenance

• Logs: sudo docker compose -f /var/lib/gravitee-am/docker-compose.yml logs -f management-api gateway
• Restart: sudo systemctl restart gravitee-am.service
• OS updates: unattended-upgrades is enabled for security patches. Reboot to apply kernel updates.
• Backups: snapshot the /var/lib/gravitee-am data disk, or pg_dump the graviteeam database from the PostgreSQL container.

Support

SecureAnyCloud maintains this image and provides 24/7 support. For help, contact SecureAnyCloud support through the Azure Marketplace listing.

Deploy on Azure

Launch Gravitee Access Management on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com