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 OPA and its declarative language called Rego. You can specify the policies that you want OPA to evaluate and act upon by writing the code manually or by configuring built-in rules to suit your requirements.
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.
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:
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.
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.
Policies and Rules
Although the terms are often used interchangeably, there is a subtle difference between a Policy and a Rule.
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.
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.
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 that is being 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 policies deployed.
You can also drill down into the details of individual operations in Decisions tab.