Skip to main content

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.

OPA-integrated Amazon API Gateway ArchitectureOPA-integrated Amazon API Gateway Architecture

Custom​

The 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 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.

OPA-integrated Emissary-Ingress Gateway ArchitectureOPA-integrated Emissary-Ingress Gateway Architecture

Entitlements​

The 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.

Styra DAS Entitlements System uses centralized Entitlements management systems for their Self-hosted custom applications. Entitlement Systems integrate custom applications with a separate system that handles all of the rules and regulations on behalf of the application.

Envoy​

The 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.

Envoy Architecture for Ingress trafficEnvoy Architecture for Ingress traffic

Envoy Architecture for Egress trafficEnvoy Architecture for Egress traffic

Gloo Edge Gateway​

The 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.

Gloo Edge Gateway Architecture for Ingress trafficGloo Edge Gateway Architecture for Ingress traffic

Istio​

The 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.

Istio Architecture for Ingress trafficIstio Architecture for Ingress traffic

Istio Architecture for Egress trafficIstio Architecture for Egress traffic

Kong Enterprise Gateway​

The 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.

OPA-integrated Kong Enterprise Gateway ArchitectureOPA-integrated Kong Enterprise Gateway Architecture

Kong Gateway​

The 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 Gateway Architecture for Ingress trafficKong Gateway Architecture for Ingress traffic

Kong Mesh​

The 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.

Kong Mesh Architecture for Ingress trafficKong Mesh Architecture for Ingress traffic

Kong Mesh Architecture for Egress trafficKong Mesh Architecture for Egress traffic

Kubernetes​

The 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.
Styra Integration with KubernetesStyra Integration with Kubernetes

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 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.

Kuma Architecture for Ingress trafficKuma Architecture for Ingress traffic

Kuma Architecture for Egress trafficKuma Architecture for Egress traffic

Terraform​

The 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 Integration with TerraformStyra Integration with Terraform

Styra DAS also supports a direct integration with Terraform Cloud and Terraform Enterprise using Terraform run tasks, which requires no infrastructure or OPA agent deployments to get up and running. See the Terraform system documentation for the full details.