Styra provides organizations that rely on a distributed, cloud-based application infrastructure with a flexible, agent-based policy monitoring, and policy enforcement solution.
The technology at the core of this solution is Open Policy Agent (OPA) and its declarative policy language, Rego. You can specify the policies that OPA evaluates and acts upon by configuring built-in rules or by writing custom policies using Rego.
A Workspace is a container for a collection of managed Systems. It provides access to individual System resources and a context for resources that span multiple Systems. Styra DAS tenants are limited to a single, tenant-level Workspace.
A System is Styra’s core unit for policy authoring, validation, and distribution, together with decision monitoring, analysis, and reporting. In Styra DAS, 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 DAS supports both pre-defined Systems, including Envoy and Kubernetes, and custom Systems 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 an Envoy Styra System.
Styra DAS supports the following System types:
- Amazon API Gateway
- Emissary-Ingress Gateway
- Gloo Edge Gateway
- Kong Enterprise Gateway
- Kong Gateway
- Kong Mesh
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). A Styra DAS System stores all the policies required for a single class of OPAs to make policy decisions for any software to which those OPAs are connected.
For Styra DAS, a System acts as a discrete boundary for defining and enforcing policies.
A Stack is a collection of Policies and a description of the Systems where the policies are applied. It organizes multiple Systems into a logical collection based on common characteristics. Stacks allow you to apply the same Policies to multiple Systems.
A Rule is a specific individual constraint. It consists of specific instructions written in the form of a Rego statement for custom Rules or specific parameters that you configure for existing Rego statements using built-in Rules.
For example, a Rule can specify only images from an explicitly authorized registry can be deployed.
A Policy is a collection of Rules. Those Rules codify a real-world Policy describing procedures or behaviors for conducting business that is typically documented in written form in an employee handbook, wiki page, or a runbook. When a Policy is applied to a System, it enforces or monitors the behavior of the System and its users.
Multiple code-based Policies distributed together are called a Policy Bundle.
Decisions and Violations
OPA makes Decisions to allow or deny operations or provide suggestions based on the corresponding System’s Policies.
If an operation violates a Policy enforced on a specific System, the operation is denied.
Different Policies within different Systems make different kinds of decisions using different Policy styles.
- For Kubernetes admission control, you can write deny rules that return error messages, and those rules can be either monitored or enforced.
- For Envoy, you can write a mix of allow and deny rules that return booleans to enforce what traffic is allowed into the microservice or out of it.
For Kubernetes Systems, if the admission controller starts sending requests before the agent has downloaded a Policy Bundle, then you may see Undefined error messages, but requests are allowed to proceed. After the agent downloads a valid Policy Bundle, it will process the requests using the deployed Policies.