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 ArchitectureCustom
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 ArchitectureEntitlements
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 traffic
Envoy Architecture for Egress trafficGloo 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 trafficIstio
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 traffic
Istio Architecture for Egress trafficKong 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 ArchitectureKong 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 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 traffic
Kong Mesh Architecture for Egress trafficKubernetes
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 KubernetesThe 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 traffic
Kuma Architecture for Egress trafficRepository Scan
The Styra DAS Repository Scan System is a special System that scans existing Kubernetes or Terraform configuration files stored in a Git repository hosted on a Git provider such as GitHub, Bitbucket, or Azure Git and analyzes the repository for risks. After Repo Scan analyzes the repository, Styra DAS generates a compliance report using policy libraries that identify best practice violations.
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 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.