Skip to main content

Overview of DAS Resources

In the enterprise, many different teams write policy for many different types of software systems. Organizing all of the policies across all of the teams and software systems is obviously important for the enterprise to leverage the benefits of a unified policy system.

The Styra DAS Graphical User Interface (GUI) comprises of the following DAS resources.

  1. A Workspace is a container for the collection of systems that you and your team manage. It provides access to individual system resources and a context for resources that span multiple systems. Currently, Styra DAS tenants are limited to a single, tenant-level workspace.

  2. A System is Styra’s core unit for policy authoring, validation, and distribution together with decision monitoring, analysis, and reporting. In Styra, a System represents a real-world software system for policy management. The real-world software system may be a physical or virtual computer node, a cluster of nodes that form a logical management boundary, or an application running on multiple nodes in a cloud instance. Styra supports both predefined system-types like Envoy and Kubernetes, as well as a Custom system-type that allows you to define other targets manually. For example, a real-world Kubernetes cluster is represented by a Kubernetes Styra system and a real-world microservice is represented by a Envoy Styra system.

    The following shows a list of system types:

    * [Custom system](/tutorials/ssh/introduction)
    * [Envoy system](/tutorials/envoy/introduction)
    * [Istio system](/tutorials/istio/introduction)
    * [Kong Mesh system](/tutorials/kong-mesh/introduction)
    * [Kubernetes system](/tutorials/kubernetes/introduction)
    * [Kuma system](/tutorials/kuma/introduction)
    * [Terraform system](/tutorials/terraform/introduction)

    For example, the real-world software system could be a Kubernetes cluster running OPA for admission control, or a deployment of microservices configured with OPA for authorization, or a collection of physical servers using OPA's Pluggable Authentication Modules (PAM). In other words, a DAS system stores all the policies required for a single class of OPAs to make policy decisions for any software those OPAs are connected to.

    For Styra, a system acts as a discrete boundary for defining and enforcing policies.
  1. A Stack is a collection of policies and a description of which systems those policies apply to. It organizes multiple systems into a logical collection based on common characteristics. Stacks allow you to apply the same policies to several systems without having to define those policies one system at a time.
  1. A Rule is a specific individual constraint. It consists of specific instructions that you write in the form of a Rego statement for custom rules, or specific parameters that you configure for existing Rego statements used in built-in rules. For example, you may define a rule that specifies only images from an explicitly authorized registry can be deployed.
  1. A Policy is a collection of rules. Those rules codify a real-world policy describing procedures or behaviors for conducting business that are typically documented in written form in an employee handbook, WIKI, or Runbook. When a policy is applied to a system, it enforces or monitors the behavior of that system and its users. Because you can distribute a complete collection of code-based policies to Styra OPA at the same time, the collection is called a Policy Bundle.

Organize Policies

The Styra DAS provides the following mechanisms for policy organization.

  • System: This is the primary unit of policy organization. A sandbox that gives a team autonomy to control the policies enforced or monitored for a single, real-world software system. The policies attached to a DAS system are exactly the policies enforced by the instances of the Open Policy Agent that are integrated with the corresponding real-world system. The team that owns that DAS system is the only one that can modify its policies, and those policies are isolated from the policies for other DAS systems. For example, there are system-types for Kubernetes and Envoy, and a Custom system-type that you can use for any OPA integration.

  • Stack: A control that ensures policy is applied correctly and consistently across all DAS systems of a particular kind. A DAS stack forcibly applies its policies to DAS systems, so that the stack policies are effectively part of the system policy. How the stack and system policies combines depends on the type of system; sometimes the stack overrides the system and sometimes it complements the system.


  • Library: A mechanism that enables teams to share policies and policy fragments across the enterprise. The policies in the library can be written for any use case by any team. The organization of the DAS Library depend on the enterprise to agree upon. The policy library can be used by either DAS systems or DAS stacks. Furthermore, the DAS (like the Open Policy Agent) enable JSON data to be used as parameters to policy that can be just as impactful in terms of making policy decisions as the policies themselves. The DAS provides a mechanism for organizing that JSON data.

  • Data Source: Provides an API for reading and writing JSON data that can be imported and used to make policy decisions. A Data source can be added to systems, stacks, or the Library so that data and the policies that utilize it can be shared however is appropriate. The data is versioned and stored compactly with a delta-encoding to handle large and frequently changing JSON. Git is a special kind of Data source that automatically pulls data out of its repository.