Use the Styra DAS to explore the following environments.
The DAS Custom system type is used when other system types fail to meet your requirements. It helps you manage any other real-world system that has been integrated with OPA. For example, you can govern public cloud resource configuration through Terraform; control who can SSH into a Linux server; or dictate the readers and writers of Kafka topics.
The DAS Envoy system type helps you manage the ingress and egress network traffic permitted within your Envoy-based service mesh. For example, permit egress traffic only to a predefined collection of endpoints, to minimize the risk of data exfiltration, and implement microservice API authorization.
Figure 1: Envoy Architecture for Ingress traffic
Figure 2: Envoy Architecture for Egress traffic
The Kong Mesh system type helps you manage 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, and implement microservice API authorization.
Figure 3: Kong Mesh Architecture for Ingress traffic
Figure 4: Kong Mesh Architecture for Egress traffic
The DAS Kubernetes system type helps a cluster administration write policies that control the resource configurations that are allowed to run on a cluster. You can ensure the following:
- All binaries run 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.
- All of those are policies you can write that the DAS with OPA can enforce.
For Kubernetes, OPA integrates within the API server itself, ensuring that any policies you put in place are authoritatively enforced by Kubernetes itself. Every change that a user makes to a Kubernetes cluster goes through the Kubernetes API server and therefore OPA. Technically, OPA integrates with the API server as an admission controller (either validating or mutating) so the policies are applied on any modification (create, update, delete), and the entire Kubernetes resource (50+ lines of YAML) are handed to OPA to decide whether the resource should be allowed onto the cluster.
The integration of DAS and OPA on your Kubernetes cluster involves the following two key components:
- Open Policy Agent (OPA) is configured as a Kubernetes admission controller. All requests that are created, updated, or deleted goes through Kubernetes admission control and therefore must be authorized by OPA before they are deployed on the cluster.
- Styra Local Control Plane (SLP) downloads policies from the 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 the DAS for analysis and to the local OPAs when policy decisions rely on those resources.
Figure 5: Styra Integration with Kubernetes
The Kubernetes system type includes a number of features that can go beyond the listed platform features.
Pre-built policy library: Get started immediately using a collection of pre-built rules to solve a plethora of operational, security, and compliance challenges across all the traditional silos of computation, networking, and storage. Put those rules in place and customize them with a point-and-click interface.
Impact analysis: Before sending that policy for review, see which resources on your actual cluster will violate that new policy. Check if you are using the customized policy library. Now, decide whether your cluster is ready for that 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 provide the auditors (and yourself) with the policies that are being enforced everywhere they need to be.
The DAS Kuma system type helps you manage 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, and implement microservice API authorization.
Figure 6: Kuma Architecture for Ingress traffic
Figure 7: Kuma Architecture for Egress traffic
The DAS Terraform system type helps you put guardrails onto the public cloud resources you manage with Terraform. For example, it requires S3 buckets to be encrypted on AWS so that your data is encrypted at rest and satisfies your compliance and security requirements.
Figure 8: Styra Integration with Terraform