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

Open original source

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

    Figure SDA-ADS-07-1 · From request to pod · © forcsguy.com

    ObjectPurpose
    PodSmallest unit: one or more containers sharing network and volumes
    ReplicaSet / DeploymentKeep N pods running; roll out updates and roll back
    ServiceStable virtual IP and DNS name that load balances to matching pods
    IngressHTTP routing from outside to services (host, path, TLS), handled by an ingress controller
    ConfigMap / SecretConfiguration and sensitive values injected as environment variables or files
    StatefulSetPods with stable identity and storage, for databases and brokers
    DaemonSetOne pod per node (log shippers, agents)
    Job / CronJobRun to completion, once or on a schedule
    NamespaceLogical 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 } }
    

    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), latest image 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

    Open this lesson with its quiz and exercise

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.

  1. Warm upGet the vocabulary first.

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

  3. ReadEngineers explain it in their own words.

  4. See it in another companyThe same ideas, a different system.

  5. Read the codeSee how it looks when it is real.

Keep learning

Loading community…