linkerd-workshop

Notes and whatnot from a Linkerd workshop: "Locking down your Kubernetes cluster with Linkerd"

# install linkerd cli
brew install linkerd

# configure kubectl and linkerd cli for minikube
export KUBECONFIG=~/.minikube/config/minikube

# do a pre-flight check prior to install linkerd
linkerd check --pre

# write the linkerd install file to this project
linkerd install > installation/linkerd-install.yaml

# apply the linkerd installation yaml
kubectl apply -f installation/linikerd-install.yaml

# generate linkerd viz on-cluster metrics dashboard
linkerd viz install > installation/viz-install.yaml

# apply viz installation yaml
kubectl apply -f installation/viz-install.yaml

# download emojivoto
curl -sL run.linkerd.io/emojivoto.yml > installation/emojivoto.yaml

# install emojivoto
kubectl apply -f installation/emojivoto.yaml

# test emojivoto out
kubectl -n emojivoto port-forward svc/web-svc 8080:80
open https://localhost:8080

# inject linkerd into emojivoto
kubectl get -n emojivoto deploy -o yaml | linkerd inject - > installation/emojivoto-injected.yaml

# apply injected app
kubectl apply -f installation/emojivoto-injected.yaml

Notes:

Blog post: https://buoyant.io/2021/12/14/locking-down-network-traffic-between-kubernetes-namespaces/

Authorization policy in 2.11
- control over communication allowed in cluster
- Linkerd (and Kubernetes) allows all communication between pods. Now it has the ability to deny communication
- In place today: server-side policies. server enforcing traffic. Only restricting connections today, not individual requests
- 2.12 will work towards client-side policies and more fine-grained policies
AuthorizationPolicy meant to be a replacement for Kubernetes NetworkPolicy
- Uses workload identity (ServiceAccount)
- built on top of mTLS (same as Linkerd in general)
- enforced at pod level (important for zero trust)
- will be able to capture L7 semantics in 2.12+
- NetworkPolicy is still better for things like UDP traffic
AuthorizationPolicy is the first possibility using Linkerd to "shoot yourself in the foot"
Mechanics:
- There's a default policy, typically set through config.linkerd.io/default-inbount-policy annotation.
  - Every cluster has a cluster-wide default policy. By default it's " all-unauthenticated" (changing nothing)
  - Default policy can be overriden at namespace or workload level
  - default policy fixed at startup time. when changed, need to restart pod
- Two new CRDs: Server and ServerAuthorization
Default policies
- all-unauthenticated - allow all
- cluster-unauthenticated - allow from clients with source IPs in cluster
- all-authenticated - allow from clients with Linkerd's mTLS
- cluster-authenticated - combination of previous two
- deny
CRDS
- Server CRD
  - selects a port over a set of pods in a namespace
  - can match multiple workloads
  - by themselves servers deny all traffic!
- ServerAuthorization CRD
  - selects over one or more servers and describes the type of traffic allowed to those servers
  - can match multiple servers
  - can allow based on what ServiceAccount the client is using
Cluster-wide default policy is the only way to apply a cluster-wide policy
When rejected
- if it's a gRPC connection: grpc-status: PermissionDenied
- if it's an HTTP connection: 403 Forbidden response code
- otherwise denial = refused TCP connection
Gotchas
1. Kubelet probes need to be authorized
  - if building a deny by default setup, need to make sure kubeletes are authorized or they won't start
2. Default policies are not read dynamically
  - can change with linkerd update cli tool command
3. Ports must be in the pod spec
  - if a server references a port, it must be in the pod spec

new commands:

 curl -sL run.linkerd.io/emojivoto-policy.yml > installation/emojivoto-policy.yaml
 kubectl apply -f installation/emojivoto-policy.yaml

At this point he was showing some of the same stuff that was being shown in the blog post above

chadxzs/linkerd-workshop-2022-01-13

linkerd-workshop