Skip to main content

Styra DAS

Modern software companies seek to embrace cloud-native technologies for strategic advantage. Cloud-Native is exemplified by Kubernetes, Microservices, Service Meshes, Containers, et al. For more information about Cloud Native Computing Foundation (CNCF), see CNCF page. The adoption of cloud-native is driven by team structure as it is by technology. Modern software companies are empowering many small, nimble teams to deliver software faster than ever. Each of those teams needs to implement authorization and policy across all the software systems they use and across all the software they build.

In the past, each team had little choice but to build or use a different authorization solution for each piece of software. Understanding or controlling what those policies said across different software required understanding different APIs, GUIs, and even policy models. Developers would need to build a custom authorization system for their application. Operations teams would automate many different ways of controlling authorization and policy for their entire stack. Security and compliance teams would dig through application code and configuration for their software portfolio to perform audits. Finally, people and machines rarely had the permissions they must have in part because of this fragmentation.

The Styra Declarative Authorization Service (DAS), built on top of the open-source project Open Policy Agent (OPA), provides a single pane of glass for authorization and policy across the cloud-native ecosystem of software systems. Using the DAS allows you to use a single language for expressing policy and a single software system for managing those policies across a broad spectrum of software systems, for example: Kubernetes, microservices, public cloud, Linux, and databases. The Styra DAS provides the world's first enterprise-grade policy-development lifecycle including policy authoring, policy testing, policy distribution, policy monitoring, and policy logging.

The Styra DAS works with any software system integrated with OPA. It provides a core feature set that applies regardless which underlying software system is integrated with OPA. As integrations become more popular the Styra DAS adds special support to help streamline installation, policy-authoring, testing, and so on. In the end, the Styra DAS provdes a unified policy-development lifecycle for any OPA use case, while at the same time providing an especially elegant experience for the most popular use cases.

Platform Features​

Styra’s DAS provides the following features for all use cases of the OPA.

  1. Policy Authoring: Write the policies you need by yourself and with other teams across the organization.

    • Tailored policies: Write rules tailored to your organization in a declarative policy language designed specifically to express policies for the cloud-native ecosystem. Use the same policy language developed as part of the OPA project and owned by CNCF.
    • Context-aware policies: Elevate decision-making to incorporate business-level information. Connect custom sources of context to make more intelligent and business-aware authorization decisions.
    • Policy-as-Code: Render your policies as code to check them into source-control and inject them into your normal cloud-native change-management processes for peer-review, rollback, and versioning.
  2. Policy Impact Analysis: Before deploying a new or updated policy, you must know what impact it will have on the real-world system.

    • Policy test framework: To help the different stakeholders within the organization ensure the correct controls are in place, have them write tests over policies themselves. As policies evolve over time those tests assure that the policies always meet business requirements.
    • Backtesting: It is important to predict the cases, test the cases, maintain a record of all the cases the real-system has seen, and backtest a new policy against those cases. Understand the decisions that are seen in the change with your new policy, even before you ask your peers for review.
  3. Distribution: Deploy policies to the systems that need them.

    • Distribution: OPA can be integrated to make decisions that get enforced or are simply monitored. OPA requires only the latest policies and the data that policy relies on. Once OPA has its policies, it makes decisions independently without any communication with the DAS. OPA makes decisions; DAS helps the organization manage OPA, its policies, and the decisions OPA makes.
    • Shift-left into CICD: For teams embracing Gitops, enforce policies as part of a Continuous Integration (CI) and Continuous Deployment or Continuous Delivery (CD) pipeline so developers get early feedback about policy violations. Policies are portable; the same ones used to enforce in a real-world system can also be used in a CICD pipeline.
  4. Monitoring and Logging: Watch the health of all your OPAs and the decisions that they are making.

    • Monitoring: OPAs are real-world systems too and need the same care and attention. It important to know the list of OPAs that are healthy, require an upgrade, or have lost the connection.
    • Decision logging and analysis: Treat the decisions that OPA makes as first-class citizens; store them in a high-fidelity, loss-less log that can be replayed and analyzed to help people understand why decisions were made the way they were, even if the decisions were made months ago.
  5. Enterprise readiness: Use the features you expect for the modern enterprise.

    • Multi-everything: Manage policy across all your clouds, clusters, servers, applications, and databases from a single pane of glass. Aggregate or drill-into the information as you like; use the Styra API to inject information into your existing security and monitoring tools; and link back to Styra for in-depth analysis.
    • Usual suspects: Single-sign on, access control, on-premise deployments.

Types of Environments​

You can explore the following types of environments by using Styra DAS.


The Kubernetes use case helps a cluster administration write policies that control the resource configurations that are allowed to run on a cluster. Want to ensure all binaries run on the cluster come from a trusted registry? Or that binaries only run with root privileges when necessary? Or that only specific network addresses can connect to specific applications? All of those are policies you can write that the DAS with OPA can enforce.

For Kubernetes, OPA integrates within the API server itself, ensuring that any policies you put in place are authoritatively enforced by Kubernetes itself. Every change that a user makes to a Kubernetes cluster goes through the Kubernetes API server and therefore OPA. Technically, OPA integrates with the API server as an admission controller (either validating or mutating) so the policies are applied on any modification (create, update, delete), and the entirety of the Kubernetes resource (those 50+ lines of YAML) are handed to OPA to decide whether the resource should be allowed onto the cluster.

The integration of DAS and OPA on your Kubernetes cluster involves the following two key components:

  • Open Policy Agent (OPA) is configured as a Kubernetes admission controller. All requests that are creates, updates, or deletes go through Kubernetes' admission control and therefore must be authorized by OPA before they are deployed on the cluster.
  • Styra local control plane (SLP) downloads policies from the DAS and relays them to the OPAs. The SLP provides an additional copy of the policies for even higher availability. The SLP also monitors Kubernetes resources and provides them as required both to the DAS for analysis and to the local OPAs when policy decisions rely on those resources.


Figure 1: Styra Integration with Kubernetes

The Kubernetes use case includes a number of features that can go beyond the listed Platform Features.

  • Pre-built policy library: Get started immediately using a collection of pre-built rules to solve a plethora of operational, security, and compliance challenges across all the traditional silos of compute, networking, and storage. Put those rules in place and customize them with a point-and-click interface.

  • Impact analysis: Before sending that policy for review, see which resources on your actual cluster will violate that new policy. Make sure if you are using the policy library that you have customized it properly. Once you are happy, decide whether your cluster is ready for that policy to be enforced.

  • Monitoring and Compliance: For policies that are too disruptive to put into place immediately, set them to monitoring mode, inform your teams that the policy is coming, and give them a dynamically-updated burn-down list of the resources they need to fix. Use that same functionality to continually search for policy violations on all your clusters to provide to auditors (and yourself) that policies are being enforced everywhere they need to be.


The Envoy use case helps an organization control the ingress and egress network traffic for individual microservices within an Envoy-based service mesh. For example, permit egress traffic only to a pre-defined collection of endpoints to minimize the risk of data exfiltration, or implement microservice API authorization to minimize lateral movement during a breach, or to implement end-user authorization within the microservice application itself.

For Envoy, OPA runs as a sidecar, and Envoy is configured to ask OPA for an authorization decision on every incoming and outgoing API request. You control the decisions made by Envoy by writing two separate policies: one that allows or denies incoming API calls and a separate policy that allows or denies outgoing API calls.