RBAC ServiceAccount களுடன் எவ்வாறு செயல்படுகிறது, மற்றும் ஒரு Kubernetes cluster ஐ எவ்வாறு பாதுகாப்பீர்கள்?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** API-இல் *யார் என்ன செய்யலாம்* என்பதை ஆளுகிறது. அனுமதிகள் **subject களுக்கு** (user கள், group கள், **ServiceAccount கள்**) resource களில் அனுமதிக்கப்பட்ட verb களைப் பட்டியலிடும் **Role களுடன்** அவற்றை **bind** செய்வதன் மூலம் வழங்கப்படுகின்றன. RBAC என்பது பரந்த cluster-hardening உத்தியின் ஒரு layer.

## RBAC model

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: permissions within ONE namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, or reusable across namespaces)

Role/ClusterRole = a set of RULES: "these VERBS on these RESOURCES"
Bindings are ADDITIVE and there is NO deny — you grant only what's needed.
```

## Role + RoleBinding எடுத்துக்காட்டு

```yaml
# A Role: read-only access to Pods in the "app" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Bind that Role to a ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccount கள்: Pod களுக்கான அடையாளம்

```text
A ServiceAccount is the IDENTITY a Pod uses to talk to the API server.
  → Every Pod gets one (the namespace "default" SA if unspecified).
  → A projected token is mounted into the Pod; RBAC decides what that token can do.
Best practice: give each workload its OWN SA with least-privilege RBAC,
and set automountServiceAccountToken: false when the Pod doesn't need API access.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # opt out if no API calls are needed
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # run Pods under this identity
```

## Defense in depth — RBAC-க்கு அப்பால்

```text
AUTH        → least-privilege RBAC; per-workload ServiceAccounts; audit access
NETWORK     → default-deny NetworkPolicies (Pods can't talk unless allowed)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) to enforce
SECRETS     → encryption at rest for etcd; external secret managers; tight RBAC on secrets
IMAGES      → scan images, use trusted registries, enforce with admission (e.g. policy engines)
API/etcd    → restrict & encrypt etcd; TLS everywhere; limit anonymous & cluster-admin access
SUPPLY CHAIN→ signed images, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # what can the current user do?
```

## இது ஏன் முக்கியம்

ஒரு cluster ஐப் பாதுகாப்பது ஒரு senior பொறுப்பு, மேலும் ServiceAccount களுடன் கூடிய RBAC அதன் அடித்தளம், எனவே இரண்டையும் புரிந்துகொள்வது அத்தியாவசியமான security அறிவு. RBAC model நேர்த்தியானது, உள்வாங்கத் தகுந்தது: அனுமதிகள் **தூய்மையாக additive, deny இல்லை**, **subject களை** (user கள், group கள், குறிப்பாக **ServiceAccount கள்**) resource களில் அனுமதிக்கப்பட்ட **verb களை** எண்ணும் **Role களுடன்** (namespaced) அல்லது **ClusterRole களுடன்** (cluster-wide) **bind** செய்வதன் மூலம் வழங்கப்படுகின்றன — இதன் பொருள் நல்ல security என்பது deny களை நம்புவதற்குப் பதிலாக ஒவ்வொரு workload உம் தேவைப்படுவதை மட்டுமே வழங்குவதிலிருந்து (**least privilege**) வருகிறது. ஒரு **ServiceAccount என்பது ஒரு Pod API ஐ அழைக்கப் பயன்படுத்தும் அடையாளம்** என்பதைப் புரிந்துகொள்வது — ஒவ்வொரு Pod உம் ஒரு token ஐப் பெறுகிறது, `default` SA என்பது ஒரு பொதுவான over-privilege பொறி, மற்றும் நீங்கள் ஒவ்வொரு workload-க்கும் அதன் சொந்த least-privilege SA ஐக் கொடுக்க வேண்டும் (மற்றும் API access தேவையில்லாதபோது token automounting ஐ முடக்க வேண்டும்) — நேரடியாக நடைமுறைப் பயனுள்ளது, மேலும் நிஜ-உலக misconfiguration-இன் அடிக்கடி மூலம். முக்கியமாக, ஒரு senior engineer RBAC என்பது **defense in depth**-இன் ஒரே ஒரு layer மட்டுமே என்பதை அறிவார்: default-deny **NetworkPolicy கள்**, hardened **securityContext** setting கள் (non-root, read-only root filesystem, dropped capabilities, seccomp), **Pod Security Admission**, Secret களுக்கான **encryption at rest** மற்றும் external manager கள், image scanning மற்றும் signing, admission controller கள் (OPA/Gatekeeper, Kyverno), மற்றும் locked-down etcd/API access அனைத்தும் ஒரு cluster ஐப் பாதுகாக்க இணைகின்றன. ஒரு Kubernetes cluster ஒரு high-value target ஆக இருப்பதால், அங்கு ஒரு ஒற்றை over-permissioned ServiceAccount அல்லது ஒரு திறந்த NetworkPolicy முழு compromise-க்கு வழிவகுக்கும், RBAC மற்றும் பரந்த hardening toolkit ஐ தேர்ச்சி பெறுவது production-இல் cluster களை பாதுகாப்பாக இயக்குவதற்கு அடிப்படையானது.

RBAC model

Role + RoleBinding எடுத்துக்காட்டு

ServiceAccount கள்: Pod களுக்கான அடையாளம்

Defense in depth — RBAC-க்கு அப்பால்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்