← Observabilidad
KUBERNETES · SEGURIDAD

Seguridad
y resource management

RBAC · NetworkPolicy · Pod Security · Requests/limits · Quotas y QoS

K8S · SEC
🔐 RBAC 🛡 NetworkPolicy 📊 Quotas ⚡ QoS
01 RBAC — quién puede hacer qué
👤
IDENTIDAD
Usuarios, grupos y ServiceAccounts
ServiceAccount token projected
Dentro del cluster lo habitual es un ServiceAccount por workload. El token montado en el Pod identifica al cliente ante el API server. Evita usar el default SA salvo casos triviales.
IRSA / Workload Identity: en cloud, el SA de K8s se mapea a un rol IAM/GCP — sin credenciales largas en Secret.
📜
ROL
Role vs ClusterRole
verbs resources
Role es namespaced; ClusterRole aplica al cluster (o se referencia desde un RoleBinding en un namespace). Los verbs (get, list, watch, create…) definen la acción.
Principio: mínimo privilegio — un deployer no necesita * sobre secrets.
🔗
BINDING
RoleBinding / ClusterRoleBinding
subjects
Une sujetos (User, Group, ServiceAccount) con un Role o ClusterRole. Un ClusterRoleBinding otorga permisos globales — revisión obligatoria en auditorías.
Comprueba: kubectl auth can-i delete pods -n prod --as=system:serviceaccount:prod:ci-bot
Cadena RBAC típica
Pod + ServiceAccount
RoleBinding
Role / ClusterRole
API Server autoriza la petición
02 Red y endurecimiento del Pod
🛡
NETWORK POLICY
Firewall declarativo entre Pods
ingress egress CNI
Sin políticas, muchos CNI permiten todo el tráfico este-oeste. Un NetworkPolicy selecciona Pods con labels y define qué orígenes/destinos y puertos están permitidos. Requiere un CNI compatible (Calico, Cilium, etc.).
Patrón: default deny en ingress y luego políticas explícitas por app; egress restringido a DNS y APIs conocidas.
🔒
POD SECURITY
PSA, context y admission
restricted baseline
Pod Security Admission (sucesor de PSP) etiqueta namespaces con niveles privileged / baseline / restricted. securityContext en Pod o contenedor: runAsNonRoot, readOnlyRootFilesystem, capabilities.drop: ["ALL"].
Validating/Mutating webhooks (OPA Gatekeeper, Kyverno) centralizan políticas: etiquetas obligatorias, imágenes firmadas, etc.
03 CPU, memoria y fairness
Concepto
Qué hace
Por qué importa
Requests
Reserva para scheduling — el scheduler coloca el Pod donde “cabe”
Sin requests, el cluster no puede planificar de forma equilibrada; Bin Packing y prioridades dependen de números reales.
Limits
Techo duro (mem) o throttling (CPU cgroup v1)
Mem sin limit = riesgo de OOM en el nodo; CPU sin limit puede hambrear a otros Pods.
QoS class
Guaranteed / Burstable / BestEffort
En presión de memoria, el kubelet mata BestEffort primero, luego Burstable que exceden requests, etc.
ResourceQuota
Límite agregado por namespace (CPU, mem, count de objetos)
Evita que un equipo monopolice el cluster; combina con LimitRange para defaults por Pod.
04 Comandos útiles
kubectl — RBAC, quotas y políticas
# ¿Puede este SA crear pods en staging?
kubectl auth can-i create pods -n staging --as=system:serviceaccount:staging:deployer

# Listar roles y bindings del namespace
kubectl get rolebindings,roles,clusterrolebindings,clusterroles -n prod

# Quotas y limit ranges
kubectl describe resourcequota -n prod
kubectl describe limitrange -n prod

# Ver QoS de cada Pod
kubectl get pods -n prod -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass
🎯
RBAC no es seguridad de red
RBAC controla el API. Para tráfico entre Pods necesitas NetworkPolicy (y TLS/mTLS entre servicios si aplica).
📓
Auditoría
Activa audit logs del API server (nivel Metadata/RequestResponse según compliance). Sin logs, no hay post-mortem de “quién escaló ese RoleBinding”.
⚖️
Requests = promesa
Pedir 100m CPU y usar constantemente 4 cores rompe el supuesto del scheduler. Ajusta con métricas reales (VPA/describe node) y revisa PriorityClass antes de abusar de prioridades.