Skip to main content

Deploying OPA on Google Cloud Run

Google Cloud Run is a fully managed platform for deploying and scaling containerized applications. It is well-suited for running off-the-shelf software packaged as containers, such as OPA, and it handles scaling, networking, and infrastructure, allowing you to focus on delivering value with your own apps.

A cloud run service is best suited to running a centralized OPA Policy Decision Point (PDP) which is called from Policy Enforcement Points (PEPs) running elsewhere. However, Cloud Run also supports running OPA as a sidecar to other application containers too.

This guide will walk you through the steps and considerations when using Cloud Run to deploy OPA.

Selecting a Container Image​

It is recommended to use the openpolicyagent/opa:<version> variant. These are available on Docker Hub and are updated as OPA is released.

Users without access to pull from Docker Hub might need to request to have these images mirrored to a private registry.

warning

Note: It is not recommended to use the latest tag in production.

Public vs. Private Endpoints​

A Cloud Run service can either be run with a public endpoint URL or a private one where callers are authenticated using Cloud IAM. Generally, as PEPs calling OPA are other internal services rather than end users, avoiding the use of a public endpoint is recommended. If your callers are not able to use Cloud IAM then a public endpoint may be necessary.

You may also wish to use Ingress control to ensure callers are from your VPC.

Authentication & Authorization Considerations​

While OPA's role is often to provide authorization decisions, OPA itself needs to authorize callers to ensure that the PEPs calling it only use the policies and endpoints they have access to.

If PEP callers are being authenticated using Cloud IAM, then they can use their token in calls to OPA to identify themselves. If not using Cloud IAM, then callers should either use a client certificate or a token. See more details here on certificate and token based authentication with OPA in the OPA documentation.

For OPA PDP services serving many PEPs, authorization is also important. Authorizing callers ensures that the expected policies are being used by each application. Review the the OPA documentation for notes of how to authorize callers.

CPU Scaling & Memory Allocation​

OPA is a lightweight service and generally does not require a lot of resources. However, in order to get low latency responses on a container platform like Cloud Run, it is recommended to run a minimum of 1 OPA instance with 1 vCPU and 512MB of available memory.

warning

OPA services should also use: CPU is always allocated so that the service is always ready to handle requests. Without this, decisions can be delayed while OPA starts causing a bad user experience.

It is also recommended to use the Second generation execution environment for for reduced latency.

If you require a large amount of data to be loaded into OPA for policy evaluation then you may need to increase the memory allocation. It is always recommended to test an OPA deployment with realistic data and traffic to ensure that the service will perform well in production.

Startup and Health Checks​

Cloud Run has functionality to run HTTP health checks on containers to ensure readiness and health of the service. It is recommended to use the /health?bundles endpoint as the startup check. This ensures that OPA has loaded the policy bundles.

The same /health endpoint (with no query parameters) should be used as the health check endpoint to ensure that OPA is running correctly after startup.

Loading OPA Configuration​

OPA needs a configuration file to operate. Most importantly, this file instructs OPA on where to find policy bundles. When running OPA in Cloud Run, it is recommended to store the OPA configuration file using Cloud Secret Manager. This can then be mounted into the running containers as a file.

In order to download our OPA configuration file from Styra DAS, we need the following parameters. These can be found under Settings > Install in the DAS UI for your system.

  • DAS API Token:
  • DAS System ID:
  • DAS Tenant URL:

To download the OPA configuration file from Styra DAS, run the following command:

curl --silent \
-H "Authorization: Bearer " \
-o opa-conf.yaml \
"/v1/systems//assets/opa-config"

Now we can use this file opa-conf.yaml when creating a new secret in Cloud Secret Manager. This will be used in the next step when creating the service's containers.

Creating the OPA Service​

This can be done using the gcloud CLI, the Google Cloud Console or a tool like Terraform. Below the required settings are listed for use in your preferred method:

  • Container Image URL: openpolicyagent/opa:<version>
  • CPU is always allocated: true
  • Minimum number of instances: 1
  • Under Volumes, create a new volume for the secret created above.
  • Under Containers...
    • Container Port: 8181
    • Container Arguments: (ensure separate arg for each word)
      • run --server --addr=:8181 --config-file=/run/secrets/YOUR_SECRET_NAME
    • Under Volume Mounts, mount the secret to /run/secrets/YOUR_SECRET_NAME
  • Execution environment: Second generation

Once the instance is running, you can access the OPA service by sending HTTP requests to the REST API.

Further Reading​

  • SDKs for building PEP applications in your language of choice.