Advanced

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-sa # => ServiceAccount name
  namespace:
    default # => Namespace-scoped resource
    # => ServiceAccounts are namespace-bound

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name:
    pod-reader # => Role name (namespace-scoped)
    # => Defines permissions within default namespace
  namespace: default
rules:
  - apiGroups:
      [""] # => Core API group (v1)
      # => Empty string represents core API
    resources:
      ["pods"] # => Resources: pods
      # => Could also include pods/log, pods/exec
    verbs:
      ["get", "list", "watch"] # => Allowed operations
      # => get: retrieve single Pod by name
      # => list: list all Pods in namespace
      # => watch: watch for Pod changes
      # => Missing: create, update, delete, patch

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name:
    read-pods-binding # => RoleBinding name
    # => Binds Role to ServiceAccount
  namespace: default
subjects:
  - kind:
      ServiceAccount # => Subject type
      # => Could also be User or Group
    name:
      pod-reader-sa # => Grants permissions to this ServiceAccount
      # => Must exist in same namespace
    namespace: default
roleRef:
  kind:
    Role # => References a Role (namespace-scoped)
    # => Could reference ClusterRole instead
  name:
    pod-reader # => References Role above
    # => Role must exist in same namespace
  apiGroup: rbac.authorization.k8s.io

---
apiVersion: v1
kind: Pod
metadata:
  name: rbac-pod
spec:
  serviceAccountName:
    pod-reader-sa # => Uses ServiceAccount
    # => Default: "default" ServiceAccount
    # => Token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token
  containers:
    - name: kubectl
      image:
        bitnami/kubectl:latest # => kubectl CLI container
        # => Uses ServiceAccount token for authentication
      command:
        - sh
        - -c
        - |
          kubectl get pods              # => Allowed (list pods)
                                        # => Role permits list verb on pods
          kubectl get services          # => Denied (no permission)
                                        # => 403 Forbidden: no services in Role
          sleep 3600

# RBAC verification:
# => kubectl auth can-i list pods --as=system:serviceaccount:default:pod-reader-sa
# => yes (Role permits list on pods)
# => kubectl auth can-i list services --as=system:serviceaccount:default:pod-reader-sa
# => no (services not in Role rules)
# => kubectl auth can-i delete pods --as=system:serviceaccount:default:pod-reader-sa
# => no (delete verb not in Role)

**Key Takeaway**: Use ServiceAccounts for Pod identity and RBAC for fine-grained permission control; follow principle of least privilege by granting only required permissions; prefer namespace-scoped Roles over cluster-wide ClusterRoles when possible.

**Why It Matters**: RBAC is the foundation of Kubernetes security in production environments, used by companies like Spotify and Airbnb to enforce least-privilege access across hundreds of microservices. Proper ServiceAccount configuration prevents privilege escalation attacks (where compromised Pods gain unauthorized cluster access) and enables compliance auditing (proving who can do what in the cluster). Without RBAC, a single vulnerable Pod could compromise the entire cluster - production clusters at Google and AWS enforce mandatory RBAC policies where every workload runs with explicitly granted permissions, never default admin access.

---

### Example 59: ClusterRole and ClusterRoleBinding

ClusterRoles define cluster-wide permissions for non-namespaced resources (nodes, PersistentVolumes) or cross-namespace access. ClusterRoleBindings grant cluster-level permissions.

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name:
    node-reader # => ClusterRole name (cluster-scoped)
    # => No namespace field (cluster-wide resource)
    # => Can be bound cluster-wide or per-namespace
rules:
  - apiGroups:
      [""] # => Core API group
      # => Empty string for core Kubernetes API
    resources:
      ["nodes"] # => Nodes are cluster-scoped resources
      # => No namespace concept for nodes
    verbs:
      ["get", "list", "watch"] # => Read-only operations
      # => Missing: create, delete, update (node management)

  - apiGroups:
      [""] # => Core API group
      # => PersistentVolumes in core API
    resources:
      ["persistentvolumes"] # => PVs are cluster-scoped
      # => Different from PVCs (namespace-scoped)
    verbs:
      ["get", "list"] # => Read-only (no watch)
      # => Sufficient for volume inventory

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:
    read-nodes-global # => ClusterRoleBinding name
    # => Cluster-scoped (no namespace field)
    # => Grants cluster-wide permissions
subjects:
  - kind:
      ServiceAccount # => Subject type
      # => ServiceAccounts are namespace-scoped
    name:
      cluster-reader-sa # => ServiceAccount name
      # => Must specify namespace for ServiceAccount
    namespace:
      kube-system # => ServiceAccount in kube-system namespace
      # => Common namespace for system components
roleRef:
  kind:
    ClusterRole # => References ClusterRole
    # => Cannot reference Role (incompatible scope)
  name:
    node-reader # => References ClusterRole
    # => ClusterRole must exist
  apiGroup:
    rbac.authorization.k8s.io # => RBAC API group
    # => Required for roleRef

# ClusterRole vs Role:
# => Role: namespace-scoped permissions (pods, services, configmaps in one namespace)
# => ClusterRole: cluster-wide permissions (nodes, PVs, all namespaces)
# => ClusterRole + RoleBinding: cluster role limited to one namespace
# => ClusterRole + ClusterRoleBinding: cluster role across all namespaces

# Common use cases:
# => Monitoring: read Pods across all namespaces
# => Node management: manage nodes (cluster-scoped)
# => PV administration: manage PersistentVolumes (cluster-scoped)
# => Cross-namespace operations: operators managing CRDs globally

**Key Takeaway**: Use ClusterRoles for cluster-wide resources like nodes and PersistentVolumes or cross-namespace access; combine ClusterRole with RoleBinding to limit cluster-wide permissions to specific namespaces.

**Why It Matters**: ClusterRoles enable platform teams at companies like Datadog and New Relic to build monitoring solutions that observe all namespaces without requiring per-namespace RBAC configuration, reducing operational overhead from hundreds of RoleBindings to a single ClusterRoleBinding. This pattern is critical for cluster-wide operators (cert-manager, ingress-nginx) that manage resources across namespaces, and for SRE teams who need read-only cluster visibility for troubleshooting without modifying workloads. Cross-namespace visibility reduces mean-time-to-recovery (MTTR) in production incidents.

---

### Example 60: Aggregated ClusterRoles

Aggregated ClusterRoles combine permissions from multiple ClusterRoles using label selectors, enabling modular permission management and extending built-in roles.

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name:
    monitoring-aggregated # => Aggregated ClusterRole
    # => Container role, rules auto-populated
  labels:
    rbac.example.com/aggregate-to-monitoring:
      "true"
      # => Self-includes in aggregation
      # => Optional but conventional
aggregationRule:
  clusterRoleSelectors:
    - matchLabels:
        rbac.example.com/aggregate-to-monitoring:
          "true"
          # => Combines all ClusterRoles with this label
          # => Label selector matches below ClusterRoles
          # => Updates automatically when matching ClusterRoles change
rules:
  [] # => Auto-populated from aggregated ClusterRoles
  # => DO NOT manually add rules here
  # => Controller overwrites manual edits

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name:
    monitoring-pods # => Component ClusterRole
    # => Aggregated into monitoring-aggregated
  labels:
    rbac.example.com/aggregate-to-monitoring:
      "true"
      # => Matched by aggregationRule above
      # => Adding this label triggers aggregation
rules:
  - apiGroups:
      [""] # => Core API group
      # => Pods are in core API
    resources:
      ["pods", "pods/log"] # => Pod resources and logs
      # => pods/log enables kubectl logs
    verbs:
      ["get", "list", "watch"] # => Read-only operations
      # => Sufficient for monitoring/observability

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name:
    monitoring-metrics # => Component ClusterRole
    # => Aggregated into monitoring-aggregated
  labels:
    rbac.example.com/aggregate-to-monitoring:
      "true"
      # => Matched by aggregationRule
      # => Can add this label to new ClusterRoles anytime
rules:
  - apiGroups:
      ["metrics.k8s.io"] # => Metrics API group
      # => Requires metrics-server installed
    resources:
      ["pods", "nodes"] # => Metrics resources
      # => kubectl top pods/nodes use these
    verbs:
      ["get", "list"] # => Read metrics
      # => No watch needed for metrics

# Aggregation result:
# => monitoring-aggregated automatically includes:
#    - pods, pods/log (get, list, watch)
#    - metrics.k8s.io/pods, metrics.k8s.io/nodes (get, list)
# => Add new ClusterRole with matching label → auto-aggregated
# => Remove label from ClusterRole → removed from aggregation
# => Useful for extensible permission systems
# => Built-in roles (admin, edit, view) use this pattern

**Key Takeaway**: Use aggregated ClusterRoles for modular permission management; add new permissions by creating ClusterRoles with matching labels; built-in roles like admin, edit, view use aggregation for extensibility.

**Why It Matters**: Aggregated ClusterRoles power Kubernetes' extensibility model, allowing Custom Resource Definitions (CRDs) to automatically extend built-in roles (admin, edit, view) without manual RBAC updates. This pattern is used by Istio, Knative, and ArgoCD to ensure their custom resources integrate seamlessly with existing RBAC policies. For platform teams building internal developer platforms, aggregation enables adding new capabilities (custom metrics, domain-specific resources) while maintaining consistent permission structures across hundreds of microservices, reducing RBAC configuration drift and security policy gaps.

---

### Example 61: SecurityContext and Pod Security

SecurityContext controls security settings at Pod and container level, including user/group IDs, privilege escalation, filesystem access, and capabilities.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-context-pod
spec:
  securityContext: # => Pod-level security settings
    runAsUser:
      1000 # => Run as user ID 1000 (non-root)
      # => Default: container image user (often root)
    runAsGroup:
      3000 # => Run as group ID 3000
      # => Primary group for process
    fsGroup:
      2000 # => Filesystem group for volumes
      # => Files owned by group 2000
      # => Enables volume sharing between containers
    fsGroupChangePolicy:
      OnRootMismatch
      # => Change ownership only if needed
      # => Alternative: Always (slower but thorough)
  containers:
    - name: secure-app
      image:
        nginx:1.24 # => Container image
        # => Image may define default user
      securityContext: # => Container-level (overrides Pod-level)
        allowPrivilegeEscalation:
          false
          # => Prevents gaining more privileges
          # => Blocks setuid binaries
        runAsNonRoot:
          true # => Ensures non-root user
          # => Container fails if user is root
          # => Validates runAsUser setting
        readOnlyRootFilesystem:
          true # => Filesystem is read-only
          # => Use volumes for writable paths
          # => Prevents malware persistence
        capabilities:
          drop:
            - ALL # => Drop all Linux capabilities
            # => Start with zero privileges
          add:
            - NET_BIND_SERVICE # => Add only required capabilities
              # => Bind to ports < 1024
              # => Minimal privilege for nginx

      volumeMounts:
        - name:
            cache # => Volume mount name
            # => Writable because readOnlyRootFilesystem=true
          mountPath:
            /var/cache/nginx # => Writable volume for cache
            # => nginx needs writable cache directory

  volumes:
    - name: cache
      emptyDir:
        {} # => Ephemeral writable storage
        # => Deleted when Pod deleted
        # => Safe for cache/temp files


# Security best practices:
# => runAsNonRoot: true (prevent root exploits)
# => readOnlyRootFilesystem: true (minimize attack surface)
# => allowPrivilegeEscalation: false (prevent privilege escalation)
# => Drop ALL capabilities, add only required (least privilege)
# => fsGroup for volume permissions (multi-container Pods)

**Key Takeaway**: Always run containers as non-root with read-only root filesystem; drop all capabilities and add only required ones; use SecurityContext to enforce defense-in-depth security practices.

**Why It Matters**: SecurityContext prevents container escape vulnerabilities that have affected Docker, containerd, and runc (CVE-2019-5736). Running as non-root with read-only filesystem blocked 80% of container attacks in Aqua Security's 2023 threat report. Companies like Shopify and Slack enforce these settings cluster-wide using Pod Security Standards, preventing developers from accidentally deploying privileged containers that could compromise the entire Kubernetes node. This defense-in-depth approach is mandatory for PCI-DSS and SOC 2 compliance.

---

### Example 62: PodSecurityPolicy (Deprecated)

PodSecurityPolicy (PSP) enforces cluster-wide security standards for Pods. PSP is deprecated in Kubernetes 1.21+ and removed in 1.25+, replaced by Pod Security Admission.

```yaml
# NOTE: PSP deprecated, use Pod Security Standards instead
# Shown for historical context and migration understanding

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted # => PSP name
spec:
  privileged: false # => Disallow privileged containers
  allowPrivilegeEscalation: false # => Prevent privilege escalation
  requiredDropCapabilities:
    - ALL # => Require dropping all capabilities
  volumes:
    - configMap
    - emptyDir
    - projected
    - secret
    - downwardAPI
    - persistentVolumeClaim # => Allowed volume types
  runAsUser:
    rule: MustRunAsNonRoot # => Enforce non-root user
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  readOnlyRootFilesystem: true # => Require read-only root filesystem

---
# Migration to Pod Security Standards (PSS)
# 1. Label namespaces with Pod Security levels
# => kubectl label namespace default pod-security.kubernetes.io/enforce=restricted
# => Levels: privileged, baseline, restricted

# 2. Pod Security Admission enforces policies
# => No PSP or RBAC setup needed
# => Built-in controller validates Pods

# 3. Restricted level enforces:
# => runAsNonRoot: true
# => allowPrivilegeEscalation: false
# => Drop ALL capabilities
# => Read-only root filesystem

# File: /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets # => Encrypt Secrets
      - configmaps # => Optionally encrypt ConfigMaps
    providers:
      - aescbc: # => AES-CBC encryption
          keys:
            - name: key1
              secret:
                <base64-encoded-32-byte-key>
                # => Generate: head -c 32 /dev/urandom | base64
      - identity: {} # => Fallback for unencrypted data


# Apply encryption:
# 1. Create encryption config file
# 2. Update kube-apiserver manifest:
#    --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
# 3. Restart kube-apiserver
# 4. Encrypt existing Secrets:
#    kubectl get secrets --all-namespaces -o json | kubectl replace -f -

# Encryption providers (ordered by preference):
# => aescbc: AES-CBC with PKCS#7 padding (default)
# => aesgcm: AES-GCM (faster, requires unique nonce)
# => secretbox: XSalsa20-Poly1305 (external library)
# => kms: External Key Management Service (AWS KMS, GCP KMS, Azure Key Vault)
# => identity: No encryption (plaintext)

# KMS provider example (AWS):
# providers:
# - kms:
#     name: aws-encryption-provider
#     endpoint: unix:///var/run/kmsplugin/socket.sock
#     cachesize: 1000
# - identity: {}

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend # => Applies to Pods with app=backend
  policyTypes:
    - Ingress # => Controls incoming traffic
    - Egress # => Controls outgoing traffic
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend # => Allow from frontend Pods
        - podSelector:
            matchLabels:
              app: database # => Allow from database Pods
      ports:
        - protocol: TCP
          port: 8080 # => Allow on port 8080 only

  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database # => Allow to database Pods
      ports:
        - protocol: TCP
          port: 5432 # => PostgreSQL port


# NetworkPolicy behavior:
# => Without NetworkPolicy: all traffic allowed
# => With NetworkPolicy: default deny, explicit allow required
# => Requires CNI plugin support (Calico, Cilium, Weave)
# => Does NOT apply to Services (applies to Pods)

# Deny all ingress traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: default
spec:
  podSelector: {} # => Applies to all Pods in namespace
  policyTypes:
    - Ingress # => Deny all incoming traffic

---
# Deny all egress traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Egress # => Deny all outgoing traffic

---
# Deny all ingress and egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress # => Complete isolation


# Apply default deny first:
# 1. kubectl apply -f deny-all.yaml
# 2. Pods cannot communicate (expected)
# 3. Create allow rules for specific traffic
# 4. Test connectivity before deploying

# Testing connectivity:
# => kubectl run test --image=busybox --rm -it -- sh
# => wget -O- http://backend-service:8080  # Blocked by NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend-namespace
  namespace: backend-ns # => Applies in backend-ns namespace
spec:
  podSelector:
    matchLabels:
      app: api # => Applies to api Pods in backend-ns
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              environment:
                frontend # => Allow from namespaces with environment=frontend label
                # => kubectl label namespace frontend-ns environment=frontend
        - podSelector:
            matchLabels:
              app: web # => AND Pods with app=web
      ports:
        - protocol: TCP
          port: 8080

# Namespace isolation patterns:
# => Production namespace: allow only from prod namespaces
# => Development namespace: allow from dev namespaces
# => Shared services: allow from multiple namespaces

# Label namespaces for NetworkPolicy:
# => kubectl label namespace frontend-ns environment=frontend
# => kubectl label namespace backend-ns environment=backend
# => kubectl label namespace prod-ns environment=production

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-external
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Egress
  egress:
    # Allow DNS resolution
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns # => Allow CoreDNS
      ports:
        - protocol: UDP
          port: 53 # => DNS port

    # Allow specific external IP
    - to:
        - ipBlock:
            cidr: 203.0.113.0/24 # => Allow to IP range
            except:
              - 203.0.113.10/32 # => Except this IP
      ports:
        - protocol: TCP
          port: 443 # => HTTPS only

    # Allow to external service
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0 # => Allow to any IP (internet)
      ports:
        - protocol: TCP
          port: 443 # => HTTPS to internet


# Egress control use cases:
# => Restrict outbound to approved APIs
# => Prevent data exfiltration
# => Control cloud provider API access
# => Block unwanted internet access

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: complex-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      tier: backend
      environment: prod # => Applies to Pods with both labels
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # Rule 1: Allow from frontend in same namespace
    - from:
        - podSelector:
            matchLabels:
              tier: frontend
      ports:
        - protocol: TCP
          port: 8080

    # Rule 2: Allow from monitoring namespace
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - protocol: TCP
          port: 9090 # => Metrics endpoint

    # Rule 3: Allow from specific IP range
    - from:
        - ipBlock:
            cidr: 10.0.0.0/8 # => Internal network
      ports:
        - protocol: TCP
          port: 8080

  egress:
    # Allow to database
    - to:
        - podSelector:
            matchLabels:
              tier: database
      ports:
        - protocol: TCP
          port: 5432

    # Allow to external API
    - to:
        - ipBlock:
            cidr: 203.0.113.50/32 # => Specific external API
      ports:
        - protocol: TCP
          port: 443

# Multiple selector behavior:
# => Multiple items in from/to are OR'd (any match allows)
# => Multiple selectors in same item are AND'd (all must match)
# => Example: podSelector AND namespaceSelector in same item

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.example.com # => CRD name: <plural>.<group>
spec:
  group: example.com # => API group
  names:
    kind: Database # => Resource kind (singular, PascalCase)
    plural: databases # => Plural name for API
    singular: database # => Singular name
    shortNames:
      - db # => Short name for kubectl
  scope: Namespaced # => Namespaced or Cluster
  versions:
    - name: v1 # => API version
      served: true # => Enable this version
      storage: true # => Storage version (one per CRD)
      schema:
        openAPIV3Schema: # => Validation schema
          type: object
          properties:
            spec:
              type: object
              properties:
                engine:
                  type: string
                  enum: ["postgres", "mysql", "mongodb"]
                version:
                  type: string
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
              required:
                - engine
                - version
            status:
              type: object
              properties:
                phase:
                  type: string
                conditions:
                  type: array
                  items:
                    type: object


# CRD creation:
# => kubectl apply -f database-crd.yaml
# => kubectl get crd databases.example.com
# => API now accepts Database resources

---
# Custom resource instance
apiVersion: example.com/v1
kind: Database
metadata:
  name: production-db
spec:
  engine: postgres
  version: "15"
  replicas: 3

# => kubectl apply -f production-db.yaml
# => kubectl get databases
# => kubectl get db production-db -o yaml

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: applications.example.com
spec:
  group: example.com
  names:
    kind: Application
    plural: applications
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                image:
                  type: string
                replicas:
                  type: integer
            status:
              type: object
              properties:
                availableReplicas:
                  type: integer
                conditions:
                  type: array

      subresources:
        status: {} # => Enable status subresource
          # => Status updates separate from spec
        scale: # => Enable scale subresource
          specReplicasPath: .spec.replicas
          statusReplicasPath:
            .status.availableReplicas
            # => kubectl scale application/myapp --replicas=5

# Subresource benefits:
# => status: separate permissions (controller updates, users read-only)
# => scale: kubectl scale integration
# => kubectl get applications shows AVAILABLE replicas

# Simplified operator pseudo-code (Go)
# Full implementation requires client-go and controller-runtime

# 1. Watch custom resources
# => watch Database resources
# => on create/update/delete events

# 2. Reconcile loop
# func reconcile(db *Database) error {
#     // Desired state from spec
#     desiredReplicas := db.Spec.Replicas
#     desiredEngine := db.Spec.Engine
#
#     // Actual state from cluster
#     actualStatefulSet := getStatefulSet(db.Name)
#     actualReplicas := actualStatefulSet.Spec.Replicas
#
#     // Reconcile
#     if actualReplicas != desiredReplicas {
#         actualStatefulSet.Spec.Replicas = desiredReplicas
#         updateStatefulSet(actualStatefulSet)
#     }
#
#     // Update status
#     db.Status.Phase = "Running"
#     db.Status.Replicas = actualReplicas
#     updateDatabaseStatus(db)
# }

# Operator responsibilities:
# => Create StatefulSet for Database
# => Create Service for Database
# => Create PVCs for persistence
# => Handle backups (CronJob)
# => Handle upgrades (rolling update)
# => Update status with current state

# Operator frameworks:
# => Operator SDK (Red Hat)
# => Kubebuilder (Kubernetes SIG)
# => KUDO (Kubernetes Universal Declarative Operator)

# Example Database operator actions:
# => spec.replicas=3 → creates StatefulSet with 3 replicas
# => spec.version="15" → updates image to postgres:15
# => spec.backup=true → creates CronJob for backups
# => status.phase → Running/Pending/Failed

# Install OLM:
# => curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.25.0/install.sh | bash -s v0.25.0

# Operator CSV (ClusterServiceVersion)
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: database-operator.v1.0.0
  namespace: operators
spec:
  displayName: Database Operator
  version: 1.0.0
  description: Manages PostgreSQL databases
  keywords:
    - database
    - postgres
  maintainers:
    - name: Platform Team
      email: [email protected]
  provider:
    name: Example Corp
  icon:
    - base64data: <base64-encoded-icon>
      mediatype: image/png
  customresourcedefinitions:
    owned:
      - name: databases.example.com
        version: v1
        kind: Database
        displayName: Database
        description: PostgreSQL Database instance
  install:
    strategy: deployment
    spec:
      deployments:
        - name: database-operator
          spec:
            replicas: 1
            selector:
              matchLabels:
                name: database-operator
            template:
              metadata:
                labels:
                  name: database-operator
              spec:
                serviceAccountName: database-operator
                containers:
                  - name: operator
                    image: example.com/database-operator:v1.0.0

# Install operator via OLM:
# => kubectl create -f database-operator-csv.yaml
# => OLM creates Deployment, ServiceAccount, RBAC
# => Operator starts managing Database resources

# Upgrade operator:
# => Create new CSV with version v1.1.0
# => OLM performs rolling update
# => Old CSV remains for rollback

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: pod-validator
webhooks:
  - name: pod-validator.example.com
    clientConfig:
      service:
        name: webhook-service
        namespace: default
        path: /validate
      caBundle: <base64-ca-cert> # => CA certificate for TLS
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"] # => Intercept Pod create/update
    admissionReviewVersions: ["v1"]
    sideEffects: None
    timeoutSeconds: 5


# Webhook server response:
# {
#   "apiVersion": "admission.k8s.io/v1",
#   "kind": "AdmissionReview",
#   "response": {
#     "uid": "<request-uid>",
#     "allowed": true/false,         # => Allow or reject
#     "status": {
#       "message": "Rejection reason"
#     }
#   }
# }

---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: pod-mutator
webhooks:
  - name: pod-mutator.example.com
    clientConfig:
      service:
        name: webhook-service
        namespace: default
        path: /mutate
      caBundle: <base64-ca-cert>
    rules:
      - operations: ["CREATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    admissionReviewVersions: ["v1"]
    sideEffects: None

# Webhook mutation response:
# {
#   "response": {
#     "uid": "<request-uid>",
#     "allowed": true,
#     "patchType": "JSONPatch",
#     "patch": "<base64-json-patch>"  # => JSON Patch to apply
#   }
# }

# Common webhook use cases:
# => Validation: enforce naming conventions, require labels
# => Mutation: inject sidecars, add default resource limits
# => Policy: prevent privileged Pods, enforce security contexts

# Chart directory structure
my-app/
├── Chart.yaml                       # => Chart metadata
├── values.yaml                      # => Default configuration values
├── templates/                       # => Kubernetes manifest templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── _helpers.tpl                # => Template helpers
└── charts/                          # => Dependency charts

# Chart.yaml
apiVersion: v2
name: my-app
description: A Helm chart for my application
type: application
version: 1.0.0                       # => Chart version
appVersion: "1.24"                   # => Application version
keywords:
- application
- web
maintainers:
- name: Platform Team
  email: [email protected]

# values.yaml
replicaCount: 3
image:
  repository: nginx
  tag: "1.24"
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80
ingress:
  enabled: false

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-app.fullname" . }}
  labels:
    {{- include "my-app.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-app.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-app.selectorLabels" . | nindent 8 }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: 80

# Helm commands:
# => helm create my-app                    # Generate chart scaffold
# => helm install my-release my-app        # Install chart
# => helm upgrade my-release my-app        # Upgrade release
# => helm rollback my-release 1            # Rollback to revision 1
# => helm uninstall my-release             # Uninstall release
# => helm list                             # List releases

# values.yaml (default values)
global:
  environment: production
replicaCount: 3
image:
  repository: nginx
  tag: "1.24"
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 200m
    memory: 256Mi

# values-dev.yaml (environment override)
global:
  environment: development
replicaCount: 1                      # => Override for dev
resources:
  requests:
    cpu: 50m                         # => Lower resources for dev
    memory: 64Mi

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-app
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: app
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        env:
        - name: ENVIRONMENT
          value: {{ .Values.global.environment }}
        resources:
          {{- toYaml .Values.resources | nindent 10 }}

# Helm install with overrides:
# => helm install dev-release my-app -f values-dev.yaml
# => Uses values-dev.yaml, merges with values.yaml
# => replicaCount=1, environment=development

# Override via --set flag:
# => helm install prod-release my-app --set replicaCount=5
# => --set overrides values.yaml

# Override precedence (highest to lowest):
# 1. --set flags
# 2. -f values-file.yaml (last file wins)
# 3. values.yaml (default)

# Chart.yaml
apiVersion: v2
name: web-application
version: 1.0.0
dependencies:
- name: postgresql                   # => Dependency chart name
  version: 12.1.5                    # => Version constraint
  repository: https://charts.bitnami.com/bitnami
                                     # => Chart repository URL
  condition: postgresql.enabled      # => Conditional dependency
- name: redis
  version: 17.9.3
  repository: https://charts.bitnami.com/bitnami
  condition: redis.enabled

# values.yaml
postgresql:
  enabled: true                      # => Enable PostgreSQL dependency
  auth:
    username: myapp
    password: changeme
    database: myapp_db
  primary:
    persistence:
      size: 10Gi

redis:
  enabled: false                     # => Disable Redis (not needed)

# Update dependencies:
# => helm dependency update
# => Downloads charts to charts/ directory
# => Creates Chart.lock with exact versions

# Chart.lock
dependencies:
- name: postgresql
  repository: https://charts.bitnami.com/bitnami
  version: 12.1.5                    # => Locked version
- name: redis
  repository: https://charts.bitnami.com/bitnami
  version: 17.9.3

# Install with dependencies:
# => helm install my-release web-application
# => Installs web-application + postgresql
# => redis not installed (enabled: false)

# Override dependency values:
# => helm install my-release web-application --set postgresql.auth.password=newsecret

# templates/db-migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-migration
  annotations:
    "helm.sh/hook": pre-upgrade       # => Run before upgrade
    "helm.sh/hook-weight": "1"        # => Hook execution order
    "helm.sh/hook-delete-policy": before-hook-creation
                                      # => Delete previous hook Job
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: migrate
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        command:
        - /bin/sh
        - -c
        - |
          echo "Running database migrations..."
          ./migrate.sh
          echo "Migrations complete"

# Available hooks:
# => pre-install: before install
# => post-install: after install
# => pre-delete: before delete
# => post-delete: after delete
# => pre-upgrade: before upgrade
# => post-upgrade: after upgrade
# => pre-rollback: before rollback
# => post-rollback: after rollback
# => test: helm test command

# Hook execution order:
# 1. Hooks with lowest weight execute first
# 2. Hooks with same weight execute in alphabetical order
# 3. Main resources deployed after hooks succeed

# Hook deletion policies:
# => before-hook-creation: delete previous hook before new one
# => hook-succeeded: delete after successful execution
# => hook-failed: delete after failed execution

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: {{ .Release.Name }}-test-connection
  annotations:
    "helm.sh/hook": test              # => Test hook
spec:
  restartPolicy: Never
  containers:
  - name: wget
    image: busybox:1.36
    command:
    - wget
    - --spider                        # => Check URL without downloading
    - {{ .Release.Name }}-service:{{ .Values.service.port }}

# Run tests:
# => helm test my-release
# => Runs Pods with helm.sh/hook: test annotation
# => Shows test results (passed/failed)

# Example test output:
# => NAME: my-release
# => NAMESPACE: default
# => STATUS: deployed
# => TEST SUITE:     my-release-test-connection
# => Last Started:   Mon Dec 30 00:00:00 2025
# => Last Completed: Mon Dec 30 00:00:05 2025
# => Phase:          Succeeded

# Common test scenarios:
# => Connection test: verify service reachable
# => Health check: verify application healthy
# => Data validation: verify database migrations succeeded
# => Integration test: verify dependencies connected

# GitOps repository structure
gitops-repo/
├── apps/
│   ├── production/
│   │   ├── app1/
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── kustomization.yaml
│   │   └── app2/
│   └── staging/
│       └── app1/
├── infrastructure/
│   ├── namespaces/
│   ├── rbac/
│   └── monitoring/
└── clusters/
    ├── prod-cluster/
    │   └── apps/
    │       └── app1.yaml         # => ArgoCD Application manifest
    └── staging-cluster/

# GitOps workflow:
# 1. Developer commits to Git
# 2. CI builds image, updates manifest with new tag
# 3. GitOps operator (ArgoCD, Flux) detects change
# 4. Operator syncs cluster state to match Git
# 5. Application deployed automatically

# GitOps benefits:
# => Single source of truth (Git)
# => Audit trail (Git history)
# => Rollback via Git revert
# => Declarative infrastructure
# => Automated deployment
# => Environment parity (same process for all envs)

# GitOps principles:
# 1. Declarative: desired state in Git
# 2. Versioned: Git provides versioning
# 3. Immutable: Git commits are immutable
# 4. Automated: reconciliation loop syncs cluster
# 5. Auditable: Git log provides audit trail

# Install ArgoCD:
# => kubectl create namespace argocd
# => kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Access ArgoCD UI:
# => kubectl port-forward svc/argocd-server -n argocd 8080:443
# => https://localhost:8080

# Get admin password:
# => kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

# ArgoCD Application CRD
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default # => ArgoCD project
  source:
    repoURL: https://github.com/example/gitops-repo
    targetRevision: HEAD # => Git branch/tag/commit
    path: apps/production/app1 # => Path in repository
  destination:
    server:
      https://kubernetes.default.svc
      # => Target cluster
    namespace: production # => Target namespace
  syncPolicy:
    automated:
      prune: true # => Delete resources not in Git
      selfHeal: true # => Auto-sync on drift
    syncOptions:
      - CreateNamespace=true # => Auto-create namespace


# Apply Application:
# => kubectl apply -f my-app-application.yaml
# => ArgoCD starts syncing repository to cluster

# ArgoCD CLI:
# => argocd login localhost:8080
# => argocd app list
# => argocd app sync my-app
# => argocd app rollback my-app