![]() ![]() The gateways are managed by the platform team and run in the Istio Gateway namespace, allowing users to plug into them, but not modify them. Istio manages Splunk’s ingress gateways, which receive traffic from public and internal NLBs. The applications send plain text HTTP requests, but the Envoy sidecar intercepts the traffic and implements Mutual TLS encryption to protect against interception or modification. One of the key benefits of Istio’s injection of Envoy sidecars is that Istio can provide in-transit encryption for the entire mesh without requiring any modifications to the applications. Istio also emits Telemetry data (metrics, logs, traces) that is useful for validating request-level security. Splunk uses Istio to enforce policy on the application layer based on the details of each request. Splunk also relies on NetworkPolicies for securing and restricting Pod to Pod connectivity. Validating Webhooks are used to prevent the deployment of K8S objects that would allow insecure traffic in the cluster (typically around NLBs and services). The next security layer in Splunk’s stack is Kubernetes itself. Aviatrix is used to provide overlapping VPC access, while also enforcing some high level security rules (segmentation per domain). In addition to ordinary east/west and north/south traffic, there are also shared services at Splunk that every cluster needs to access. As an example, we restrict public connectivity to our Ingress nodes (that will deploy Envoy ingress gateways). ![]() ![]() Within each VPC, Network ACLs and Security Groups are set up to restrict connectivity to what is absolutely required. Additionally, this pattern avoids the possibility of RFC 1918 private IP exhaustion when leveraging many clusters. This keeps Pods and Nodes from separate clusters completely isolated, while allowing traffic outside the cluster to have particular rules enforced in the public and internal subnets. Securing Layer 3/4: AWS, Aviatrix and KubernetesĪt Splunk Cloud, we use a pattern called “cookie cutter VPCs” where each cluster is provisioned with it’s own VPC, with identical private subnets for Pod and Node IPs, a public subnet for ingress and egress to and from the public internet, and an internal subnet for traffic between clusters. Today Splunk Cloud consists of over 35 fully replicated clusters in AWS and GCP in regions around the world. Splunk Cloud is an initiative to move Splunk’s internal infrastructure to a cloud native architecture. It is primarily used for searching, monitoring, and analyzing machine-generated big data through a web-style interface. Splunk is a technology company that provides a platform for collecting, analyzing and visualizing data generated by various sources. Splunk uses a variety of tools to secure their network, including: Along the way, we’ll see what it takes to provide comprehensive network security for your cloud native stack, how these tools interoperate, and where some of them can improve. This post will explore the tools and practices leveraged by Splunk to secure their Kubernetes network infrastructure, starting with VPC design and connectivity and going all the way up the stack to HTTP Request based security. How many tools do you need? When is your network secure enough? What is often less clear is how these tools interoperate to provide comprehensive security for your network in production. With dozens of tools for securing your network available, it is easy to find tutorials and demonstrations illustrating how these individual tools make your network more secure by adding identity, policy, and observability to your traffic. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |