Extending Security with wasmCloud 1.0 and Open Policy Agent

From the beginning, wasmCloud has used zero-trust architectural patterns and Wasm's intrinsic isolation to deliver secure-by-default distributed computing. Our security posture was validated in an October 2023 audit from OSTIF and Trail of Bits, where we received excellent marks. It's important, however, that our approach to security is not only robust and default, but extensible.

With wasmCloud 1.0, our flexible, pluggable policy service API integrates easily with standard cloud native tooling like Open Policy Agent. As you take wasmCloud to production, operators can use the tools they're already using to extend and tailor the platform's already-deep security.

How it works

If you're coming from the world of Kubernetes, you can think of the wasmCloud policy service as analogous to a Kubernetes admissions controller.

When you start a wasmCloud host, it can be configured to send out policy requests on a NATS topic like wasmcloud.policy. If you enable an external policy server to handle those requests, then it can send permissions or denials back on the same NATS topic, determining whether the host is allowed to start an application component, start a capability provider, or let a component invoke a capability provider.

With this simple, pluggable design, operators can extend the security of wasmCloud with their own logic and their tools of choice, including industry standards like Open Policy Agent.

Using Open Policy Agent with wasmCloud

Open Policy Agent (OPA) is essentially the industry standard for cloud native policy evaluation, bringing together a rules engine and a policy evaluation language called rego.

In our wasmcloud/examples repository on GitHub, we've included a sample policy server using OPA as a policy engine, as well as a sample policy.rego file. The OPA server is a simple Go binary that you can test out with your own policy if you'd like—all you need is a Go toolchain, NATS running locally, and a wasmCloud host with the policy topic set via host config.

The test server is available as inspiration for your own policy server, but what's more interesting is the policy itself. It's worth showing the example policy in full, because it's both simple and powerful:

package wasmcloud.access

default allow = false

# This policy service isn't concerned with invocations, so allow them immediately
allow {
    input.kind == "performInvocation"
}

# Rule to allow access if conditions are met for startComponent
allow {
    input.kind == "startComponent"
    has_claims
    issued_by_wasmcloud
}

# Rule to allow access if conditions are met for startProvider
allow {
    input.kind == "startProvider"
    has_claims
    issued_by_wasmcloud
}

# Check if the claims object exists (ensure the component is signed)
has_claims {
    input.request.claims != null
}

# Check if the issuer is wasmCloud's official issuer
issued_by_wasmcloud {
    input.request.claims.issuer == "ACOJJN6WUP4ODD75XEBKKTCCUJJCY5ZKQ56XVKYK4BEJWGVAOOQHZMCW"
}

In this policy package, wasmcloud.access, we're allowing only wasmCloud-signed artifacts to start in the host. So if the policy server receives a request to run a component with claims that is issued by wasmCloud (i.e., a wasmCloud example or capability provider), the component will be allowed to run. Anything else will be denied. Policy itself is simple to write: our rules are implemented via if statements checking that the request has claims, and that the issuer is wasmCloud's official issuer.

You could use a similar pattern for your own organization, or implement your own logic to fit your needs. If you'd like step-by-step instructions to run this example, check out the examples repository.

Conclusion

As wasmCloud reaches 1.0, we want it to be easy to integrate with your existing cloud native patterns, such as using OPA for policy evaluation. The policy service API is designed to be easily extensible, and we're excited to see how the community builds on it.

For more information on policy and wasmCloud security, see the wasmCloud docs—especially our page on preventing untrusted workloads. There you can find the scheme for policy requests and responses and more. To talk security (or anything else) with the wider wasmCloud community, we'd love for you to join us on the wasmCloud Slack.