Authentication and Authorization in K8s
- Authentication answers
who is making this request - K8s Api server does
- Authentication
- Authorization (RBAC)
- Admission Control: Should this request be modified or validated
- who can authenticate to k8s
- User
- Service Account (Pod identity)
- External System
Authorization
- There are 4 main components
- Role: This defines permissions inside a specific namespace
- Cluster-Role: This defines permissions across whole cluster
- RoleBinding: Rolebinding connects user/group/serviceaccount to Role
- ClusterRoleBinding: Same as role binding but for binding cluster roles
- Refer Here for roles
-
Prompt:
create a new user and configure kubeconfig with certificate authentication in k8s
Service Mesh
- A service mesh is a dedicated infrastrucure layer for managing service-to-service communication
- mutual – tls
- retry and circuit breaking
-
Traffic splitting
-
If you implement this inside each app
- code becomes complex
- Hard to standardize
- Service mesh moves networking logic out of application code
- Service mesh injects sidecars into pods
- A sidecar is an extra container inside same pod, application does not know it exists (Envoy)
- Data Plane => All sidecar proxies
- Control plane => Brain of Service mesh
- Control plan is responsible for
- Traffic management
- mTLS
- Observability
- Popular service meshes
- Istio
- Linkerd
- Consul
Istio
- This is a service mesh implementation for k8s that manages service-service communication.
- It adds
- mTLS
- Traffic Managment
- Observability
- Policy enforcement
- Zero-trust secureity
-
Istio Architecture
-
Core Istio Traffic Resources (CRDS)
- Virtual Service: Controls how traffic is route and used for
- Canary
- A/B Testing
- Path Based Routing
- Header Based Routing
- Destination Rule: Defines subsets and policies
- Gateway: Controls external traffic into mesh
- mTLS in istio, Modes such as
- DISABLE
- PERMISSIVE
- STRICT
- Observability
- Virtual Service: Controls how traffic is route and used for
