1. Service Accounts:
   - Default for pods
   - JWT tokens
   - Automatic mounting
   - Namespace-scoped

2. User Certificates:
   - x509 client certificates
   - CN for username
   - O for groups
   - Long-lived

3. OIDC Tokens:
   - External identity providers
   - Google, Azure AD, Okta
   - Short-lived tokens
   - SSO integration

4. Webhook Authentication:
   - Custom authentication
   - External auth service
   - Flexible integration

Components:
- Role: Permissions in namespace
- ClusterRole: Cluster-wide permissions
- RoleBinding: Bind role to user/group
- ClusterRoleBinding: Cluster-wide binding

Example Role:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Example RoleBinding:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Admission Controllers:
- Validate requests
- Mutate requests
- Enforce policies

Built-in Controllers:
- NamespaceLifecycle: Prevent ops in terminating namespaces
- LimitRanger: Enforce resource limits
- ServiceAccount: Auto-inject service accounts
- ResourceQuota: Enforce quotas
- PodSecurityPolicy: Enforce security policies

Custom Controllers:
- Webhook-based
- External validation
- Custom business logic

Example:
1. User creates pod
2. API server calls admission webhooks
3. Webhooks validate/mutate
4. If approved: Create pod
5. If rejected: Return error

Default Deny:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Allow Specific Traffic:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Implementation:
- Enforced by CNI plugin
- iptables or eBPF rules
- Namespace isolation
- Pod-to-pod control

mTLS (Mutual TLS):
- Automatic certificate generation
- Certificate rotation
- Encrypted pod-to-pod traffic
- Identity verification

Authorization:
- Fine-grained access control
- JWT-based authentication
- Policy enforcement
- Audit logging

Implementation (Istio):
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
spec:
  selector:
    matchLabels:
      app: backend
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET", "POST"]

Levels:
- Privileged: Unrestricted
- Baseline: Minimally restrictive
- Restricted: Heavily restricted

Restricted Policy:
- No privileged containers
- No host namespaces
- No host ports
- Read-only root filesystem
- Run as non-root
- Drop all capabilities
- No privilege escalation

Implementation:
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Image Scanning:
- Scan for vulnerabilities
- Scan for malware
- Scan for secrets
- Block high-severity CVEs

Admission Controller:
- Validate image signatures
- Check scan results
- Enforce image policies
- Block unsigned images

Image Policy:
apiVersion: v1
kind: ImagePolicy
spec:
  rules:
  - action: DENY
    matchImages:
    - pattern: "*:latest"
    reason: "Latest tag not allowed"
  - action: ALLOW
    matchImages:
    - pattern: "myregistry.com/*"
    signedBy: ["trusted-signer"]

etcd Encryption:
- Encrypt secrets in etcd
- Use KMS for key management
- Key rotation
- Audit access

Configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-key>
  - identity: {}

Key Rotation:
1. Add new key to config
2. Restart API servers
3. Re-encrypt all secrets
4. Remove old key

Integration with Vault:
- Store secrets in Vault
- Sync to Kubernetes
- Automatic rotation
- Centralized management

Implementation:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-secret
spec:
  secretStoreRef:
    name: vault
  target:
    name: db-secret
  data:
  - secretKey: password
    remoteRef:
      key: database/password

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]
  
- level: Metadata
  resources:
  - group: ""
    resources: ["pods", "services"]

- level: None
  resources:
  - group: ""
    resources: ["events"]

Levels:
- None: Don't log
- Metadata: Log metadata only
- Request: Log metadata + request
- RequestResponse: Log everything

Storage:
- Write to file
- Forward to SIEM
- Store in Elasticsearch
- Retention: 1 year

Analysis:
- Detect suspicious activity
- Compliance reporting
- Security investigations
- Access patterns

Control Plane:
- API server hardening
- etcd security
- Controller manager security
- Scheduler security

Worker Nodes:
- Kubelet security
- Container runtime security
- Network security
- Storage security

Policies:
- RBAC enabled
- Admission controllers enabled
- Audit logging enabled
- Secrets encrypted
- Network policies enforced

Requirements:
- Access controls
- Encryption
- Monitoring
- Incident response
- Change management

Implementation:
- RBAC for access control
- TLS for encryption
- Prometheus for monitoring
- Audit logs for compliance
- GitOps for change management

Phases:
1. Detection:
   - Automated monitoring
   - Anomaly detection
   - Security alerts

2. Containment:
   - Isolate affected pods/nodes
   - Block malicious traffic
   - Preserve evidence

3. Eradication:
   - Remove malicious containers
   - Patch vulnerabilities
   - Update policies

4. Recovery:
   - Restore from clean state
   - Verify security
   - Resume operations

5. Post-Mortem:
   - Root cause analysis
   - Update procedures
   - Prevent recurrence

Detection:
- Privileged container created
- Host namespace access
- Suspicious syscalls
- File system modifications

Response:
1. Kill container immediately
2. Quarantine node
3. Investigate breach
4. Patch vulnerability
5. Update security policies

Prevention:
- Pod security policies
- No privileged containers
- Read-only root filesystem
- Drop all capabilities