Chainguard Container for cerbos

Cerbos is the open core, language-agnostic, scalable authorization solution that makes user permissions and authorization simple to implement and manage by writing context-aware access control policies for your application resources.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/cerbos:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The Chainguard cerbos image is a drop-in replacement for the upstream cerbos/cerbos container image. It is fully compatibile with the official cerbos Helm charts and supports all core functionality of the cerbos application. This image is designed to be a minimal, secure alternative that runs as a non-root user. Switching to this image should not require any changes to your existing deployment configuration.

Getting Started

Kubernetes Helm Chart Deployment

You can deploy this image using the official cerbos Helm charts. Be sure to override the image to use the cerbos Chainguard Image by setting the following values in a values.yaml file:

image:
  repository: cgr.dev/ORGANIZATION/cerbos
  release: latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard registry.

Then, deploy the cerbos Helm chart, as shown in the following shell example.

helm repo add cerbos oci://ghcr.io/cerbos/helm-charts/cerbos
helm repo update
HELM_EXPERIMENTAL_OCI=1 helm install cerbos oci://ghcr.io/cerbos/helm-charts/cerbos -f values.yaml --wait

You can verify that the Cerbos Helm chart deployed successfully with kubectl, as shown in the following command. This will show you the Cerbos pod running from the chart's deployment.

kubectl get pods | grep cerbos

Docker Container Deployment

To deploy Cerbos using Docker, you can do so using the docker run command. By default, Cerbos listens on port 3592 for HTTP requests, and port 3593 for gRPC requests, requiring that these ports be exposed. Execute the following command in your terminal to deploy Cerbos with its default configuration. Please note that the -d flag is included to run the container in a detached state, as otherwise Cerbos logs would occupy the terminal.

docker run -d -p 3592:3592 -p 3593:3593 --name "cerbos" cgr.dev/ORGANIZATION/cerbos

When you are finished with this container, you can remove it with the docker rm command, as follows:

docker rm cerbos

To apply custom policies and configurations to Cerbos, the /policies and /config directories are mounted volumes at runtime. To demonstrate this, begin by using the following commands to create these directories and navigate to them.

mkdir -p ~/chainguard_cerbos_demo/policies
mkdir -p ~/chainguard_cerbos_demo/config
cd ~/chainguard_cerbos_demo

Then, copy the following YAML data into a new file, policies/derived_roles_common.yaml:

cat > policies/derived_roles_common.yaml << 'EOF'
---
apiVersion: "api.cerbos.dev/v1"
derivedRoles:
  name: common_roles
  definitions:
    - name: owner
      parentRoles: ["user"]
      condition:
        match:
          expr: request.resource.attr.owner == request.principal.id
EOF

Repeat this process for the configuration of policies/resource_album.yaml:

cat > policies/resource_album.yaml << 'EOF'
---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  importDerivedRoles:
    - common_roles
  resource: "album:object"
  rules:
    - actions: ['*']
      effect: EFFECT_ALLOW
      derivedRoles:
        - owner

    - actions: ['view:public']
      effect: EFFECT_ALLOW
      roles:
        - user
      condition:
        match:
          expr: request.resource.attr.public == true
EOF

To apply a custom Cerbos configuration, we repeat the process once more for the config/conf.yaml file. Note that this configuration establishes a username linky and password LinkyAdmin, which is utilized for demonstrative purposes only, and should be changed in production use.

cat > config/conf.yaml << 'EOF'
---
server:
  httpListenAddr: ":3592"
  grpcListenAddr: ":3593"
  adminAPI:
    adminCredentials:
      passwordHash: JDJ5JDEwJGcuRHZ4MFR5a0FQUEZOU1pPMTdkbS5RV242MFY2Um9HYVR0eUpLMzdEQzZxU3g2Wi5SM3kuCgo= # echo "LinkyAdmin" | htpasswd -niBC 10 cerbos | cut -d ':' -f 2 | base64
      username: linky
    enabled: true

storage:
  driver: "disk"
  disk:
    directory: "/policies"
    watchForChanges: true

audit:
  enabled: true # Set to false to completely disable audit logging.
  accessLogsEnabled: true # Log API access attempts
  decisionLogsEnabled: true # Log policy decisions
  backend: local # Audit backend to use.
  local: # Configuration for the local audit backend
    storagePath: /auditlogs # Path to store the data
    retentionPeriod: 168h # Records older than this will be automatically deleted
EOF

With all configurations and policies in place, we are ready to deploy our container using the following docker run command:

docker run -d -p 3592:3592 -p 3593:3593 -v $(pwd)/policies:/policies -v $(pwd)/config:/config --name "cerbos" cgr.dev/ORGANIZATION/cerbos server --config=/config/conf.yaml

The Cerbos container will now be running with our custom configuration settings. We can test this deployment by sending a simple request to the Cerbos server, using cURL as follows.

curl --silent -H "Content-Type: application/json" \
    --data-binary @- \
    "http://localhost:3592/api/check/resources?pretty" << 'EOF'
{
  "requestId": "quickstart",
  "principal": {
    "id": "linky",
    "roles": [
      "user"
    ],
    "attr": {
      "beta_tester": true
    }
  },
  "resources": [
    {
      "actions": [
        "view:public",
        "comment"
      ],
      "resource": {
        "kind": "album:object",
        "id": "LINKY001",
        "attr": {
          "owner": "linky",
          "public": false,
          "flagged": false
        }
      }
    },
    {
      "actions": [
        "view:public",
        "comment"
      ],
      "resource": {
        "kind": "album:object",
        "id": "WOLFI002",
        "attr": {
          "owner": "wolfi",
          "public": true,
          "flagged": false
        }
      }
    }
  ]
}
EOF

You should receive the following in response, reflecting the successful application of the configured Cerbos policies:

{
  "requestId": "quickstart",
  "results": [
    {
      "resource": {
        "id": "LINKY001",
        "kind": "album:object"
      },
      "actions": {
        "comment": "EFFECT_ALLOW",
        "view:public": "EFFECT_ALLOW"
      }
    },
    {
      "resource": {
        "id": "WOLFI002",
        "kind": "album:object"
      },
      "actions": {
        "comment": "EFFECT_DENY",
        "view:public": "EFFECT_ALLOW"
      }
    }
  ]
}

We can also verify that the Admin API service was configured correctly with the use of the cerbosctl Chainguard Image. First, pull this image from the Chainguard registry using the following command.

docker pull cgr.dev/ORGANIZATION/cerbosctl

With the image pulled locally, execute the following command in your terminal to use cerbosctl to query the cerbos Chainguard Image's Admin API for its resource_policies.

docker run --rm --network host cgr.dev/ORGANIZATION/cerbosctl get resource_policies --plaintext --username linky --password LinkyAdmin

The response from the Admin API should be similar to the following output.

POLICY ID               NAME            VERSION SCOPE
resource_album.yaml     album:object    default

The same can be repeated for a query for Cerbos' derived_roles:

docker run --rm --network host cgr.dev/ORGANIZATION/cerbosctl get derived_roles --plaintext --username linky --password LinkyAdmin

The expected output for this request is shown in the following snippet.

POLICY ID                    NAME
derived_roles_common.yaml    common_roles

To clean up your system after completing this demonstration, be sure to run the following commands.

rm -r ~/chainguard_cerbos_demo && docker rm "cerbos"

Documentation

• Cerbos GitHub Repository
• Cerbos Helm Charts
• Cerbos Documentation

What are Chainguard Containers?

Chainguard Containers are minimal container images that are secure by default.

In many cases, the Chainguard Containers tagged as :latest contain only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager. Chainguard Containers are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a -dev variant.

Although the -dev container image variants have similar security features as their more minimal versions, they feature additional software that is typically not necessary in production environments. We recommend using multi-stage builds to leverage the -dev variants, copying application artifacts into a final minimal container that offers a reduced attack surface that won’t allow package installations or logins.

Learn More

To better understand how to work with Chainguard Containers, please visit Chainguard Academy and Chainguard Courses.

In addition to Containers, Chainguard offers VMs and Libraries. Contact Chainguard to access additional products.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.