Deploy Cerbos to Cloud platforms

This documentation is for a previous version of Cerbos. Choose 0.39.0 from the version picker at the top right or navigate to https://docs.cerbos.dev for the latest version.

AWS Marketplace

Cerbos is avaliable via the AWS Marketplace and can be deployed in either Elastic Kubernetes Service (EKS) or Elastic Container Service (ECS). When deploying Cerbos via the Marketplace, your Cerbos Hub account is included with the purchase via AWS and no additional paid account is required.

Elastic Kubernetes Service (EKS)

Step 1: Create an IAM policy

To deploy Cerbos from AWS Marketplace, you need to assign an IAM policy with appropriate IAM permission to a Kubernetes service account before starting the deployment. You can either use AWS managed policy arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage or create your own IAM policy.

Here’s an example IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "aws-marketplace:RegisterUsage"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Step 2: Create an IAM role for the Kubernetes service account (IRSA)

Once the IAM role has been created, a Kubernetes service account needs to be created and assicated with the role. We recommend doing this via eksctl. The command below automates the process to:

Create an IAM role with AWS-managed IAM policy (or you can provide your own ARN).
Create a Kubernetes service account name cerbos-serviceaccount in the cluster.
Set up a trust relationship between the IAM role and the service account.
Modify cerbos-serviceaccount annotation to associate it with the created IAM role

Remember to replace CLUSTER_NAME with your actual Amazon EKS cluster name and optionally set the namespace.

eksctl create iamserviceaccount \
    --name cerbos-serviceaccount \
    --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage \
    --namespace default \
    --cluster CLUSTER_NAME \
    --approve \
    --override-existing-serviceaccounts

Step 4: Deploy Cerbos with the service account

Requires a Cerbos Hub account.

For the following steps, you need a Cerbos Hub account with a workspace connected to your policy repository and a set of client credentials. See the Cerbos Hub getting started guide for details.

Create a new Kubernetes secret to hold the Cerbos Hub credentials - see the Cerbos Hub guide for details.

kubectl create secret generic cerbos-hub-credentials \
   --from-literal=CERBOS_HUB_CLIENT_ID=YOUR_CLIENT_ID \ (1)
   --from-literal=CERBOS_HUB_CLIENT_SECRET=YOUR_CLIENT_SECRET \ (2)
   --from-literal=CERBOS_HUB_WORKSPACE_SECRET=YOUR_WORKSPACE_SECRET (3)

1	Client ID from the Cerbos Hub credential
2	Client secret from the Cerbos Hub credential
3	Cerbos Hub workspace secret

Create a new values file named hub-values.yaml with the following contents:

# Use the AWS Marketplace image
image:
  repository: 709825985650.dkr.ecr.us-east-1.amazonaws.com/cerbos/cerbos

# Assign the service account
serviceAccount:
  name: cerbos-serviceaccount

# Set Cerbos configuration
cerbos:
  config:
    # Configure the Hub storage driver
    storage:
      driver: "hub"
      # Configure deployment label. Alternatively, add `CERBOS_HUB_BUNDLE=` to the secret you created above.
      hub:
        remote:
          bundleLabel: "YOUR_LABEL" <1>

    # Configure the Hub audit backend
    audit:
      enabled: true <2>
      backend: "hub"
      hub:
        storagePath: /audit_logs

# Create environment variables from the secret.
envFrom:
  - secretRef:
      name: cerbos-hub-credentials

# Mount volume for locally buffering the audit logs. A persistent volume is recommended for production use cases.
volumes:
  - name: cerbos-audit-logs
    emptyDir: {}

volumeMounts:
  - name: cerbos-audit-logs
    mountPath: /audit_logs

1	The label to watch for bundle updates. See deployment labels documentation for details.
2	Enables audit log collection. See Hub audit log collection documentation for information about masking sensitive fields and other advanced settings.

Deploy Cerbos using the Helm chart

helm install cerbos cerbos/cerbos --version=0.38.1 --values=hub-values.yaml

Elastic Container Service (ECS)

Step 1: Create ECS Task Role policy

To deploy Cerbos from AWS Marketplace, you need to create an ECS Task AIM Role with appropriate IAM permission before starting the deployment. You can either use AWS managed policy arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage or create your own IAM policy.

Here’s an example IAM policy required - you will need the ARN for this role when defining the task.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
          "aws-marketplace:RegisterUsage"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Step 2: Create the task definition

In the AWS console or the CLI, create the task using the following JSON definition, subsituting the values noted:

{
  "family": "cerbos",
  "containerDefinitions": [
    {
      "name": "cerbos",
      "image": "709825985650.dkr.ecr.us-east-1.amazonaws.com/cerbos/cerbos:0.38.1",
      "cpu": 0,
      "portMappings": [
        {
          "name": "cerbos-3592-tcp",
          "containerPort": 3592,
          "hostPort": 3592,
          "protocol": "tcp",
          "appProtocol": "http"
        },
        {
          "name": "cerbos-3593-tcp",
          "containerPort": 3593,
          "hostPort": 3593,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "environment": [
        {
          "name": "CERBOS_HUB_CLIENT_ID",
          "value": "YOUR_CLIENT_ID" <1>
        },
        {
          "name": "CERBOS_HUB_CLIENT_SECRET",
          "value": "YOUR_CLIENT_SECRET" <2>
        },
        {
          "name": "CERBOS_HUB_WORKSPACE_SECRET",
          "value": "YOUR_WORKSPACE_SECRET" <3>
        },
        {
          "name": "CERBOS_HUB_BUNDLE",
          "value": "YOUR_LABEL" <4>
        }
      ],
      "command": [
        "server",
        "--set=audit.enabled=true", <5>
        "--set=audit.backend=hub",
        "--set=audit.hub.storagePath=/tmp"
      ],
      "environmentFiles": [],
      "mountPoints": [],
      "volumesFrom": [],
      "ulimits": [],
      "healthCheck": {
        "command": [
            "CMD",
            "/cerbos",
            "healthcheck"
        ],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 5
      },
      "systemControls": []
    }
  ],
  "taskRoleArn": "TASK_ROLE_ARN", <6>
  "executionRoleArn": "TASK_EXECUTION_ROLE_ARN", <7>
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "cpu": "1024",
  "memory": "3072",
  "runtimePlatform": {
    "cpuArchitecture": "X86_64",
    "operatingSystemFamily": "LINUX"
  }
}

1	Client ID from the Cerbos Hub credential
2	Client secret from the Cerbos Hub credential
3	Cerbos Hub workspace secret
4	The label to watch for bundle updates. See deployment labels documentation for details.
5	Enables audit log collection. See Hub audit log collection documentation for information about masking sensitive fields and other advanced settings.
6	The ARN for the custom ECS Task Role defined in Step 1.
7	The ARN for the ECS Task Execution. The default is `arn:aws:iam::<AWS_ACCOUNT_ID>:role/ecsTaskExecutionRole`

Step 4: Launch a service

Using the above task defintion, launch a service in your ECS Cluster. Take note to ensure the service is running attached to the security groups which your applications will be calling Cerbos from.

Fly.io

You can deploy Cerbos on Fly.io as a Fly Launch app. The following fly.toml file shows how to deploy Cerbos with healthchecks and metrics:

app = '<APPLICATION_NAME>' (1)
primary_region = '<REGION>' (2)

[build]
  image = 'ghcr.io/cerbos/cerbos:0.38.1'

[[mounts]]
  source = 'policies'
  destination = '/policies'
  initial_size = '1GB'

[[services]]
  protocol = ''
  internal_port = 3592

[[services.ports]]
    port = 3592
    handlers = ['tls', 'http']

[[services.http_checks]]
    interval = '5s'
    timeout = '2s'
    grace_period = '5s'
    method = 'get'
    path = '/_cerbos/health'
    protocol = 'http'

[[services]]
  protocol = ''
  internal_port = 3593

[[services.ports]]
    port = 3593
    handlers = ['tls']

    [services.ports.tls_options]
      alpn = ['h2']

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1

[metrics]
  port = 3592
  path = "/_cerbos/metrics"

1	The name of the Fly App
2	Pick a Fly.io region

The example above launches a Cerbos instance with the minimal configuration using an empty Fly volume mounted as the policy directory. For production use cases, consider using one of the following methods for policy storage.

Your host or service for an application should be listening on the right address within the VM: Fly Proxy reaches services through a private IPv4 address on each VM, so the process should listen on 0.0.0.0:<port> (but see A note on IPv4 and IPv6 wildcards).

Cerbos git driver with a Git provider such as GitHub or GitLab
Cerbos blob driver with Tigris
Cerbos sqlite3 driver with a standalone SQLite database or LiteFS
Cerbos postgres driver with Fly Postgres
Cerbos Hub

Cerbos can be configured entirely from the command line using --set flags. On the Fly.io platform, they can be set by overriding the cmd setting in the experimental section of the fly.toml file.

Using Tigris as a policy repository

Cerbos blob driver can be used with any S3-compatible blob storage backend such as Tigris.

Create a storage bucket on Tigris. Refer to https://fly.io/docs/reference/tigris/#create-and-manage-a-tigris-storage-bucket for more information about creating storage buckets.

flyctl storage create

Note down the credentials for accessing the bucket and save them as application secrets.

flyctl apps create <APPLICATION_NAME> (1)
flyctl secrets set --app=<APPLICATION_NAME> AWS_ACCESS_KEY_ID=tid_XXXXXX (2)
flyctl secrets set --app=<APPLICATION_NAME> AWS_SECRET_ACCESS_KEY=tsec_XXXXXX (3)

1	Your application name on Fly.io
2	Tigris key ID
3	Tigris secret access key

Create a fly.toml file.

app = '<APPLICATION_NAME>' (1)
primary_region = '<REGION>' (2)

[build]
  image = 'ghcr.io/cerbos/cerbos:0.38.1'

[experimental]
  cmd = [
    'server',
    '--set', 'storage.driver=blob',
    '--set', 'storage.blob.bucket=s3://<BUCKET_NAME>?endpoint=fly.storage.tigris.dev&region=auto', (3)
    '--set', 'storage.blob.downloadTimeout=30s',
    '--set', 'storage.blob.prefix=policies',
    '--set', 'storage.blob.updatePollInterval=15s',
    '--set', 'storage.blob.workDir=/policies'
  ]

[[mounts]]
  source = 'policies'
  destination = '/policies'
  initial_size = '1GB'

[[services]]
  protocol = ''
  internal_port = 3592
  auto_stop_machines = true

[[services.ports]]
    port = 3592
    handlers = ['tls', 'http']

[[services.http_checks]]
    interval = '5s'
    timeout = '2s'
    grace_period = '5s'
    method = 'get'
    path = '/_cerbos/health'
    protocol = 'http'

[[services]]
  protocol = ''
  internal_port = 3593
  auto_stop_machines = true

[[services.ports]]
    port = 3593
    handlers = ['tls']

    [services.ports.tls_options]
      alpn = ['h2']

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1

[metrics]
  port = 3592
  path = "/_cerbos/metrics"

1	The name of the Fly App
2	Pick a Fly.io region
3	Storage bucket name

Deploy the app.

flyctl deploy

Using LiteFS as a policy repository

Fly.io’s distributed SQLite storage layer LiteFS can be used for policy storage using Cerbos' sqlite3 driver.

Start by creating an app on Fly.io.

flyctl apps create <APPLICATION_NAME>

Create a LiteFS configuration file named litefs.yml.

data:
  dir: "/var/lib/litefs"

exec:
  - cmd: "/cerbos server --set=storage.driver=sqlite3 --set=storage.sqlite3.dsn=file:/litefs/db --set=server.adminAPI.enabled=true --set=server.adminAPI.adminCredentials.username=$CERBOS_ADMIN_USER --set=server.adminAPI.adminCredentials.passwordHash=$CERBOS_ADMIN_PASSWORD_HASH"

exit-on-error: false

fuse:
  dir: "/litefs"

lease:
  advertise-url: "http://${FLY_ALLOC_ID}.vm.${FLY_APP_NAME}.internal:20202"
  candidate: ${FLY_REGION == PRIMARY_REGION}
  consul:
    url: "${FLY_CONSUL_URL}"
    key: "${FLY_APP_NAME}/primary"
  promote: true
  type: "consul"

Refer to Configuring LiteFS documentation for other available configuration parameters.

Create a Dockerfile.

FROM flyio/litefs:0.5 AS litefs

FROM ghcr.io/cerbos/cerbos:0.38.1 AS cerbos

FROM alpine:3.16 AS base
RUN apk add fuse3 sqlite
ADD litefs.yml /etc/litefs.yml
COPY --from=cerbos /cerbos /cerbos
COPY --from=litefs /usr/local/bin/litefs /usr/local/bin/litefs

ENTRYPOINT ["litefs"]
CMD ["mount"]

Create a fly.toml file to launch Cerbos.

app = '<APPLICATION_NAME>' (1)
primary_region = '<REGION>' (2)

[build]
  dockerfile = "Dockerfile"

[mounts]
  source = "litefs"
  destination = "/var/lib/litefs" (3)

[[services]]
  protocol = ''
  internal_port = 3592

[[services.ports]]
    port = 3592
    handlers = ['tls', 'http']

[[services.http_checks]]
    interval = '5s'
    timeout = '2s'
    grace_period = '5s'
    method = 'get'
    path = '/_cerbos/health'
    protocol = 'http'

[[services]]
  protocol = ''
  internal_port = 3593

[[services.ports]]
    port = 3593
    handlers = ['tls']

    [services.ports.tls_options]
      alpn = ['h2']

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1

[metrics]
  port = 3592
  path = "/_cerbos/metrics"

1	The name of the Fly App
2	Pick a region
3	Destination must be equal to the one specified in the `litefs.yaml`

Create secrets to hold Cerbos Admin API credentials. Refer to password hash generation instructions to learn how to generate the password hash.

flyctl secrets set CERBOS_ADMIN_USER=<ADMIN_USER_NAME>
flyctl secrets set CERBOS_ADMIN_PASSWORD_HASH=<ADMIN_PASSWORD_HASH>

Attach to Consul to manage LiteFS leases.

flyctl consul attach

See lease configuration for more information about Consul leases on Fly.io.

Finally, deploy Cerbos.

flyctl deploy

You can interact with the Cerbos Admin API using one of the Cerbos SDKs or the cerbosctl utility to manage the policies stored on LiteFS.

List policies with cerbosctl

cerbosctl \
  --server=<APPLICATION_NAME>.fly.dev:3593 \
  --username=<ADMIN_USER_NAME> \
  --password=<ADMIN_PASSWORD> \
  get rp

Put a policy or a directory consisting of multiple policies with cerbosctl

cerbosctl \
  --server=<APPLICATION_NAME>.fly.dev:3593 \
  --username=<ADMIN_USER_NAME> \
  --password=<ADMIN_PASSWORD> \
  put policies -R \
  policy_dir