KCNA Ep 5: Cloud Native Security & GitOps Practices

TL;DR (Quick Summary)

#

• RBAC: Role-Based Access Control enforcing Least Privilege (Subject -> RoleBinding -> Role).
• NetworkPolicies: Layer 4 firewall rules controlling ingress/egress traffic between Pods.
• GitOps: Git repository as the Single Source of Truth for infrastructure and deployment state (ArgoCD, Flux).
• Service Mesh: Dedicated infrastructure layer managing service-to-service communication, mTLS encryption, traffic routing, and observability (Istio, Linkerd).

1. Role-Based Access Control (RBAC) Architecture

#

RBAC regulates access to Kubernetes API resources based on user roles within an organization.

graph TD
    subgraph Subject ["Subject (Who)"]
        User["User / ServiceAccount"]
    end

    subgraph Connector ["Binding (Connector)"]
        RB["RoleBinding / ClusterRoleBinding"]
    end

    subgraph Rules ["Permission (What)"]
        R["Role / ClusterRole
(verbs: ['get', 'list'], resources: ['pods'])"]
    end

    User -->|Bound by| RB
    RB -->|Refers to| R

• Role vs ClusterRole:
  • Role: Namespace-scoped permissions (e.g., view pods inside development namespace).
  • ClusterRole: Cluster-scoped permissions (e.g., view nodes, persistent volumes, or all namespaces).
• Verbs: Operations allowed on resources: get, list, watch, create, update, patch, delete.

2. GitOps Principles & Workflow

#

GitOps is an operational framework that takes DevOps best practices used for application code—such as version control, code review, and automated CI/CD—and applies them to infrastructure automation.

graph LR
    Dev["Developer"] -->|1. Git Commit / PR| GitRepo["Git Repository
(Single Source of Truth)"]
    GitRepo -->|2. Detect Drift| GitOpsEngine["GitOps Controller
(ArgoCD / Flux)"]
    GitOpsEngine -->|3. Sync Manifests| K8sCluster["Kubernetes Cluster"]

The 4 Core Principles of GitOps (OpenGitOps Standard)

#

1. Declarative: The entire system state must be described declaratively in Git.
2. Versioned and Immutable: Desired state is stored in Git, creating an auditable revision log.
3. Pulled Automatically: Software agents continuously pull desired state from Git (Push vs Pull model).
4. Continuously Reconciled: Software agents continuously observe actual cluster state and automatically heal any configuration drift.

3. Service Mesh Concepts (Istio / Linkerd)

#

A Service Mesh handles high-density service-to-service communication using transparent sidecar proxies (like Envoy) deployed alongside application containers.

graph TD
    subgraph PodA ["Pod A"]
        AppA["App Container A"] <--> ProxyA["Envoy Sidecar Proxy"]
    end

    subgraph PodB ["Pod B"]
        ProxyB["Envoy Sidecar Proxy"] <--> AppB["App Container B"]
    end

    ProxyA <-- Mutual TLS (mTLS) Encrypted Tunnel --> ProxyB

Key Capabilities of a Service Mesh

#

• Mutual TLS (mTLS): Automatic transparent encryption and identity verification for service-to-service traffic without code changes.
• Traffic Management: Canary releases, A/B testing, circuit breaking, and request retries.
• Observability: Automatic generation of latency, throughput, and error metrics for HTTP/gRPC calls.

4. Key KCNA Exam Practice Questions

#

Question 1

#

In GitOps methodology, what serves as the single source of truth for the desired state of infrastructure and application deployments?

• A) The etcd database inside the cluster
• B) The Git version control repository (Correct)
• C) The Docker container registry
• D) The Prometheus metrics store

Rationale: GitOps dictates that all environment manifests must reside in a versioned Git repository as the canonical source of truth.

Question 2

#

What cloud-native technology transparently provides Mutual TLS (mTLS) encryption, traffic splitting, and circuit breaking for service-to-service traffic?

• A) Ingress Controller
• B) Service Mesh (e.g., Istio, Linkerd) (Correct)
• C) Container Network Interface (CNI)
• D) Container Runtime Interface (CRI)

Rationale: Service Meshes deploy sidecar proxies alongside application containers to manage mTLS, routing, and telemetry transparently.

Summary & Certification Completion

#

Congratulations! You have completed the KCNA (Kubernetes & Cloud Native Associate) preparation track:

• Episode 1: CNCF Ecosystem & Cloud Native Architecture
• Episode 2: Kubernetes Fundamentals & Control Plane
• Episode 3: Container Orchestration & Workload Primitives
• Episode 4: Telemetry, Observability & Monitoring
• Episode 5: Cloud Native Security & GitOps Practices

You are now ready to tackle the CKAD (Certified Kubernetes Application Developer) track starting in the next section!