Library / Case Studies
Hardening Kubernetes Infrastructure with Cilium at Palantir
A real-world engineering write-up from Palantir on distributed Security.
By Palantir engineers · Palantir · Added 2026-10-12
All content belongs to Palantir engineers / Palantir. We only link to it and give credit. Report a problem
Learn this case study
About 37 min left. Your work is saved as you go.
What you are about to study
Palantir explains a real system. You should know the basics: caching, queues and replication.
Ideas you will meet
- Distributed Systems
- Consensus, time, failure and the fundamentals of scale-out.
- Kubernetes
- Container orchestration, scheduling and service discovery.
- Web Security
- OWASP risks, XSS, CSRF, CORS and secure design.
What we already know about this
Our own lessons on these ideas. Read them here before you start, so it makes sense.
Advanced Distributed Systems · 13 minKubernetes essentialsPods, deployments, services, ingress and operators: the building blocks of the most common container platform and how a request reaches a pod.Read here
What Kubernetes does
Kubernetes (K8s) runs containers across a cluster of machines. You describe the desired state (for example "three copies of this image, reachable at this address") and controllers continuously make reality match it: restarting failed containers, replacing lost nodes and rolling out new versions. (Containers themselves are introduced in the cloud models lesson.)
The cluster
- Control plane: the API server (everything talks to it), etcd (the consistent store of cluster state, built on Raft; see the consensus lesson), the scheduler (decides which node runs a pod) and controllers (reconcile desired and actual state).
- Nodes: machines that run pods, each with a node agent (kubelet), a container runtime and a networking component.
The core objects
100%Figure SDA-ADS-07-1 · From request to pod · © forcsguy.com
Object Purpose Pod Smallest unit: one or more containers sharing network and volumes ReplicaSet / Deployment Keep N pods running; roll out updates and roll back Service Stable virtual IP and DNS name that load balances to matching pods Ingress HTTP routing from outside to services (host, path, TLS), handled by an ingress controller ConfigMap / Secret Configuration and sensitive values injected as environment variables or files StatefulSet Pods with stable identity and storage, for databases and brokers DaemonSet One pod per node (log shippers, agents) Job / CronJob Run to completion, once or on a schedule Namespace Logical separation of resources and quotas PersistentVolume(Claim) Durable storage requested by pods Networking in one paragraph
Every pod gets its own IP and can reach every other pod without NAT. Because pods are short-lived, clients use Services (found through cluster DNS such as
orders.shop.svc). Network policies restrict which pods may talk to which. An Ingress (or the newer Gateway API) handles external HTTP(S) traffic.A deployment and a rolling update
apiVersion: apps/v1 kind: Deployment metadata: { name: web } spec: replicas: 3 selector: { matchLabels: { app: web } } strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 0 } } template: metadata: { labels: { app: web } } spec: containers: - name: web image: example/web:1.4.2 resources: { requests: { cpu: 200m, memory: 256Mi }, limits: { memory: 512Mi } } readinessProbe: { httpGet: { path: /healthz, port: 8080 } }100%Figure SDA-ADS-07-2 · Rolling update · © forcsguy.com
Probes: readiness decides if a pod receives traffic; liveness decides if it should be restarted; startup gives slow starters time. Requests and limits tell the scheduler how much CPU and memory a pod needs and cap what it can use.
Autoscaling
A Horizontal Pod Autoscaler adds or removes pods by metrics such as CPU or request rate; a cluster autoscaler adds or removes nodes when pods cannot be placed. Scaling is useless without correct resource requests.
Extending Kubernetes: operators and CRDs
A Custom Resource Definition (CRD) adds a new object type (for example
PostgresCluster). An operator is a controller that watches those objects and does the operational work (create replicas, take backups, fail over), encoding human runbooks as code. Many databases and brokers ship operators.Things that often go wrong
Missing readiness probes (traffic to pods not ready), no resource requests (noisy neighbours, evictions),
latestimage tags (unrepeatable deploys), secrets in plain config, a single replica for a critical service, and running stateful systems without understanding storage and failure behaviour.Real-world reading
Related reading
- TechWorld with Nana: Docker & KubernetesNana Janashia · TechWorld with NanaYouTube
- AWS Containers BlogAmazon Web Services engineers · Amazon Web ServicesBlogs
- Awesome KubernetesRamit Surana · ramitsuranaGitHub
- Kubernetes ConceptsKubernetes Authors · CNCF / KubernetesDocumentation
Show 6 moreShow fewer
- Kubernetes: IngressKubernetes · CNCF / KubernetesDocumentation
- Docker BlogDocker engineers · DockerBlogs
- DevOps Roadmaproadmap.sh community · roadmap.shCourses
- Kubernetes BlogKubernetes community · CNCF / KubernetesBlogs
- From bare-metal to Kubernetes at BetabrandBetabrand engineers · BetabrandCase Studies
- Large-scale cluster management at Google with Borg (paper)Verma et al. · GooglePapers
Go deeper on this
A path through videos, articles, other case studies and code on the same ideas as Hardening Kubernetes Infrastructure with Cilium at Palantir.
Warm upGet the vocabulary first.
Books · Free from the author
Concurrent and Distributed Systems (Cambridge lecture notes)
Eight lectures on time, broadcast, replication, consensus and transactions, with notes, slides and video. Free from the author under CC BY-SA.
University of CambridgeIntermediate
Books · Free from the author
Computer Networks: A Systems Approach
How networks are built and why: protocols, routing, congestion control and the internet's architecture. The authors publish it free online under CC BY 4.0.
Systems ApproachIntermediate
WatchHow others solve the same problem, on video.
Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)
ReadEngineers explain it in their own words.
Papers · Read here
Large-scale cluster management at Google with Borg (paper)
The internal cluster manager that inspired Kubernetes.
GoogleAdvanced
Blogs · Free from the author · Read here
Scalable Web Architecture and Distributed Systems
A full chapter on the building blocks of large websites: availability, performance, reliability, scalability, caches, proxies, indexes, load balancers and queues. Free to read here under CC BY 3.0.
The Architecture of Open Source ApplicationsBeginner40 min
See it in another companyThe same ideas, a different system.
Case Studies · Read here
Clock Skew when Syncing Password Payloads at Drobbox
How Dropbox Passwords fixed sync errors from clock skew by replacing a two-way timestamp merge with a three-way merge against a base payload.
DrobboxIntermediate
Case Studies · Read here
High Availability with Distributed DB on Kubernetes at Airbnb
Traditionally, organizations have deployed databases on costly, high-end standalone servers using sharding for scaling as a strategy. As data demands grew, the limitations of this strategy became increasingly evident ...
AirbnbIntermediate
Read the codeSee how it looks when it is real.
GitHub
Awesome Kubernetes
Resources for learning and operating Kubernetes, from tutorials to production tooling.
ramitsuranaIntermediate
GitHub
Engineering Blogs
A huge directory of company engineering blogs to learn from real production systems.
kilimchoiIntermediate
Keep learning
Loading community…