Styra DAS Systems
Styra DAS has several pre-defined System types.
Amazon API Gateway
The Styra DAS Amazon API Gateway System manages client API requests permitted within an OPA-integrated Amazon API Gateway. For example, permit API requests only to predefined backend APIs to minimize the risk of data exfiltration and implement microservice API authorization.

Custom
The Styra DAS Custom System is used if there is not a pre-defined System type for your environment. It helps you manage any other real-world Systems integrated with OPA. For example, you can govern public cloud resource configuration, control who has SSH access to a Linux server, or define the authorized readers and writers of Kafka topics.
Emissary-Ingress Gateway
The Styra DAS Emissary-Ingress Gateway System manages the client API requests permitted within your OPA-integrated Emissary-Ingress Gateway. For example, permit API requests only to predefined backend APIs to minimize the risk of data exfiltration or implement microservice API authorization.

Entitlements
The Styra DAS Entitlements System provides a cloud-native Entitlements service which is easily integrated into existing applications, replicated globally, and managed and governed through a single pane of glass.
The motivation for the Styra DAS Entitlements System is that many organizations are already accustomed to using a centralized Entitlements management system for their Self-hosted custom applications. Instead of hard-coding into every software application the rules and regulations about what type of users can perform the actions and when they can perform the actions, developers can instead integrate those custom applications with a separate system that handles all of those rules and regulations on behalf of the application.
Envoy
The Styra DAS Envoy System manages the ingress and egress network traffic permitted within your Envoy-based proxy. For example, permit egress traffic only to a predefined collection of endpoints to minimize the risk of data exfiltration or implement microservice API authorization.


Gloo Edge Gateway
The Styra DAS Gloo Edge System manages ingress network traffic permitted within your OPA integrated Gloo Edge Gateway (which is Envoy based API gateway). For example, permit ingress traffic only to a predefined collection of endpoints to minimize the risk of data exfiltration and implement microservice API authorization.

Istio
The Styra DAS Istio System manages the ingress and egress network traffic permitted within your OPA-integrated Istio service mesh. For example, permit egress traffic only to a predefined collection of endpoints to minimize the risk of data exfiltration or implement microservice API authorization.


Kong Enterprise Gateway
The Styra DAS Kong Enterprise Gateway System manages the client API requests permitted within your OPA-integrated Kong Enterprise Gateway. For example, permit API requests only to predefined backend APIs to minimize the risk of data exfiltration and implement microservice API authorization.

Kong Gateway
The Styra DAS Kong Gateway System manages the client API requests permitted within your OPA-integrated Kong Gateway. For example, permit API requests only to a predefined backend APIs to minimize the risk of data exfiltration or implement microservice API authorization.

Kong Mesh
The Styra DAS Kong Mesh System manages the ingress and egress network traffic permitted within your OPA-integrated Kong Mesh. For example, permit egress traffic only to a predefined collection of endpoints to minimize the risk of data exfiltration or implement microservice API authorization.


Kubernetes
The Styra DAS Kubernetes System is used by a cluster administrator to write Policies which control the resource configurations that are allowed to run on a cluster. For example, you can ensure:
- All binaries running on the cluster come from a trusted registry.
- Binaries only run with root privileges when necessary.
- Only specific network addresses can connect to specific applications.
For Kubernetes, OPA integrates with the API server, ensuring that any Policies you put in place are authoritatively enforced by Kubernetes. Every change that a user makes to a Kubernetes cluster goes through the Kubernetes API server and OPA. OPA integrates with the API server as an admission controller (either validating or mutating) so that Policies are applied on any modification (create, update, delete), and the entire Kubernetes resource are sent to OPA to decide whether the resource should be allowed onto the cluster.
The integration of Styra DAS and OPA on your Kubernetes cluster involves the following two key components:
- OPA is configured as a Kubernetes admission controller. All create, update, or delete requests go through Kubernetes admission control and must be authorized by OPA before they are deployed on the cluster.
- Styra Local Control Plane (SLP) downloads Policies from Styra 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 Styra DAS for analysis and to the local OPAs when Policy decisions rely on those resources.

The Kubernetes System includes a number of features which go beyond other Systems features.
Pre-built Policy library: Get started immediately using a collection of pre-built Rules to solve operational, security, and compliance challenges across all the traditional silos of computation, networking, and storage. Put Rules in place and customize them with the Styra DAS interface.
Impact analysis: Before sending a Policy for review, see which resources on your cluster will violate the new Policy. Check if you are using the customized Policy Library and decide whether your cluster is ready for the 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 the same functionality to continually search for Policy violations on all your clusters to prove to auditors and your team that the Policies are being enforced everywhere they need to be.
Kuma
The Styra DAS Kuma System manages the ingress and egress network traffic permitted within your OPA-integrated Kuma Service Mesh. For example, permit egress traffic only to a predefined collection of endpoints to minimize the risk of data exfiltration or implement microservice API authorization.


Terraform
The Styra DAS Terraform System puts guardrails on public cloud resources managed with Terraform. For example, you can require all S3 buckets to be encrypted on AWS to ensure your data is encrypted at rest and satisfies your compliance and security requirements.

Styra DAS also supports a direct integration with Terraform Cloud using Terraform Cloud's Run Tasks, which require no infrastructure or agent deployments to get up and running. See the Terraform Cloud tutorial for the full details.