In my previous guide, How OAuth 2.0 Works: A Practical Guide for Backend Developers, I briefly touched on the mysterious state parameter and noted that its core purpose is protecting authorization flows against CSRF attacks.

At the time, we treated CSRF as a quick prerequisite concept. Today, we're taking a much deeper dive.

Perhaps you were building a REST API in Spring Boot, ran into unexpected HTTP 403 Forbidden errors on every POST request, and "fixed" it by adding .csrf(csrf -> csrf.disable()) to your Security Filter Chain.

Most tutorials treat CSRF as a checkbox item or a framework toggle. They immediately jump to code:

// What most tutorials show on line 1:
http.csrf(Customizer.withDefaults());

Starting with framework configuration hides how web security actually operates. Spring Security doesn't invent security rules out of thin air. It responds to the fundamental mechanics of web browsers, HTTP protocols, and cookies.

In this handbook, we'll take a bottom-up, first-principles approach. We won't talk about Spring Security until we've thoroughly explored browsers, HTTP headers, session management, and the underlying mechanics of Cross-Site Request Forgery.

By the end of this guide, you'll understand:

• Why browsers automatically attach credentials to outgoing requests.

• Why that automatic behavior creates a fundamental vulnerability.

• Why attackers never need to steal or read your cookies to exploit CSRF.

• Why Same Origin Policy (SOP) and CORS don't prevent CSRF.

• How modern defenses, from CSRF Tokens to SameSite cookies, work under the hood.

• How Spring Security implements these defenses internally and how to configure them effectively.

Let’s begin by stripping away frameworks and looking at how the web actually works.

Table of Contents

• The Problem Before CSRF

• Why Browsers Automatically Send Cookies

• When Automatic Cookies Become Dangerous

• Visualize the Attack

• Why the Browser Isn't Broken

• Same Origin Policy (SOP)

• Why CORS Does NOT Prevent CSRF

• Safe Methods and State Mutation

• CSRF Tokens (Synchronizer Token Pattern)

• Double Submit Cookie Pattern

• SameSite Cookies

• Origin and Referer Headers

• JWT and CSRF: The Token Storage Dilemma

• Spring Security CSRF Internals

• Implement CSRF Protection Yourself

• Testing CSRF Protections

• Common Misconceptions

• Production Best Practices Checklist

• Final Summary & Defense Matrix

The Problem Before CSRF

To understand security, we must first understand state.

The Hypertext Transfer Protocol (HTTP) is inherently stateless. This means that if Alice sends an HTTP request to travelbuddy.com (our example) at 10:00 AM, and sends another HTTP request to travelbuddy.com at 10:01 AM, the server treats those two requests as completely isolated, unrelated events.

Without a mechanism to remember Alice between requests, Alice would have to send her username and password inside every single HTTP request she makes. That would be horrific for both user experience and performance.

Before session mechanisms were standard, developers tried passing credentials via query parameters or basic authentication headers on every click. This led to credential exposure in server logs, browser histories, and URL shares.

How Do Sessions and Cookies Solve This?

To solve this, web engineers introduced the concept of Server-Side Sessions and HTTP Cookies.

When Alice logs into TravelBuddy by sending her username and password via a POST request to https://travelbuddy.com/login, the server verifies her credentials. Instead of asking Alice to log in again on the next page, the server creates a Session in its memory (or in a database/Redis cache) and assigns it a unique, unpredictable identifier: a Session ID.

The server then sends this Session ID back to Alice’s browser using a special HTTP response header: Set-Cookie.

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: JSESSIONID=abc123xyz789; Path=/; Secure; HttpOnly

When Alice’s browser receives this response, it sees the Set-Cookie header. It extracts JSESSIONID=abc123xyz789 and stores it inside its internal storage unit: the Browser Cookie Jar.

Now, Alice is "logged in". The server remembers her via that session record, and the browser holds the key (JSESSIONID) to that session.

Why Browsers Automatically Send Cookies

Now we arrive at the pivotal design choice made in the early days of the web.

Once the browser stores JSESSIONID=abc123xyz789 in its cookie jar for the domain travelbuddy.com, how does that cookie get sent back to the server on subsequent requests?

Does the developer have to write custom JavaScript to attach the cookie? No.

Browsers are explicitly designed to handle cookie management automatically.

The Request Lifecycle and Automatic Cookie Attachment

Every time Alice's browser prepares an HTTP request to https://travelbuddy.com (whether caused by Alice clicking a link, submitting an HTML form, or JavaScript triggering a fetch() call), the browser follows this exact process:

1. URL Inspection: The browser examines the destination URL (for example, https://travelbuddy.com/api/connections).

2. Cookie Jar Lookup: The browser scans its cookie jar for any stored cookies whose domain and path match travelbuddy.com.

3. Validation Check: It verifies if the cookie has expired, and if flags like Secure (requires HTTPS) are respected.

4. Header Injection: If valid cookies match, the browser automatically injects a Cookie header into the outgoing HTTP request payload.

Here's what the outgoing request looks like as it leaves Alice's machine:

POST /api/connections/add HTTP/1.1
Host: travelbuddy.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept: text/html,application/xhtml+xml
Cookie: JSESSIONID=abc123xyz789
Content-Type: application/x-www-form-urlencoded

service=SkyScanner

Notice something critical: Neither Alice nor any custom frontend JavaScript explicitly attached Cookie: JSESSIONID=abc123xyz789.

The browser's internal engine attached it automatically before sending the byte stream across the network. From the server's perspective, receiving Cookie: JSESSIONID=abc123xyz789 is proof that the request originated from an authenticated session belonging to Alice.

This automatic behavior is convenient. It makes web browsing seamless across page reloads and link navigation. But as we'll soon see, this convenience leaves a backdoor wide open.

When Automatic Cookies Become Dangerous

Is automatic cookie inclusion a vulnerability by itself?

No. If Alice only visits travelbuddy.com, automatic cookie inclusion works exactly as intended.

The vulnerability emerges because of a simple web reality: Alice visits multiple websites in the same browser session.

Enter evil.com

Suppose Alice is logged into TravelBuddy in Tab 1. Her session cookie (JSESSIONID=abc123xyz789) sits safely inside her browser's cookie jar for travelbuddy.com.

In Tab 2, Alice visits an unrelated website: https://evil.com (perhaps she clicked a link in a phishing email or a forum post).

evil.com is controlled by an attacker. The attacker knows that TravelBuddy has a feature located at POST [https://travelbuddy.com/api/connections/add that connects third-party services. The attacker wants to trick Alice into connecting the attacker's malicious service to her account.

The attacker embeds the following hidden HTML form inside the HTML page served by evil.com:

<!-- Hosted on https://evil.com/win-a-car.html -->
<!DOCTYPE html>
<html>
<body>
  <h1>You won a free trip! Click below to claim.</h1>
  
  <!-- Hidden Form targeting TravelBuddy -->
  <form id="maliciousForm" action="https://travelbuddy.com/api/connections/add" method="POST">
    <input type="hidden" name="service" value="MaliciousAttackerService" />
  </form>

  <script>
    // Automatically submit the form as soon as the page loads
    document.getElementById('maliciousForm').submit();
  </script>
</body>
</html>

Walkthrough of the Attack Execution

Let's trace step-by-step what happens when Alice opens https://evil.com/win-a-car.html:

1. Alice's browser fetches and parses HTML from evil.com.

2. The browser encounters the <script> tag and executes document.getElementById('maliciousForm').submit().

3. The browser prepares an outgoing POST request targeting https://travelbuddy.com/api/connections/add.

4. The browser looks at the target destination: travelbuddy.com.

5. The browser checks its Cookie Jar: "Do I have any active cookies for travelbuddy.com?"

6. Yes! It finds JSESSIONID=abc123xyz789 (Alice's active session cookie from Tab 1).

7. The browser automatically injects Cookie: JSESSIONID=abc123xyz789 into the outgoing request payload heading to travelbuddy.com.

8. The request lands on the TravelBuddy Spring Boot backend server.

The Server's Perspective

Here's what the TravelBuddy backend sees when processing the request:

POST /api/connections/add HTTP/1.1
Host: travelbuddy.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=abc123xyz789

service=MaliciousAttackerService

The TravelBuddy server checks the Cookie header. It validates JSESSIONID=abc123xyz789 against its session store. The session is valid: it belongs to Alice!

The server assumes: "Alice sent a POST request to add MaliciousAttackerService. She is authenticated, so I will grant this request."

The server updates Alice's account state. MaliciousAttackerService is now connected to her profile.

The Core Realization of CSRF

Take a step back and examine what just happened:

1. The attacker NEVER saw or stole Alice’s session cookie. The attacker on evil.com can't read cookies belonging to travelbuddy.com due to browser isolation rules.

2. The attacker did NOT break encryption. HTTPS was active the entire time.

3. The attacker simply induced Alice's browser to make a request. The browser, faithfully executing its automatic cookie attachment rules, provided the credentials on behalf of the attacker. You could say the attacker got caught with their hand in Alice's cookie jar!

This is Cross-Site Request Forgery in action: An attacker tricks a victim's browser into executing an unwanted, state-changing HTTP request to a trusted site where the victim is currently authenticated.

Visualize the Attack

Visualizing the interaction between Alice, the browser, evil.com, and TravelBuddy makes the underlying request flow clear.

1. The Complete CSRF Sequence

The attack unfolds across three distinct phases involving four main actors: Alice, her web browser, the TravelBuddy backend server, and the attacker site running on evil.com.

In the first phase, Alice authenticates with TravelBuddy. She submits her login credentials through her browser, which sends a POST request to the TravelBuddy backend. The backend verifies her credentials and responds with an HTTP 200 OK status alongside a Set-Cookie header containing JSESSIONID=abc123xyz.

Upon receiving this response, Alice's browser automatically saves this session identifier inside its cookie jar for the travelbuddy.com domain.

In the second phase, the attacker sets a trap. While keeping her TravelBuddy tab active, Alice opens a second browser tab and visits evil.com. Her browser requests the page win-a-car.html from evil.com. In response, evil.com serves an HTML document containing an invisible form targeting TravelBuddy, paired with an embedded JavaScript script designed to trigger immediately upon loading.

In the final phase, the attack executes automatically. The malicious JavaScript on evil.com calls form.submit(), commanding the browser to send a POST request to https://travelbuddy.com/api/connections/add.

Before sending the request across the network, the browser checks its cookie jar for any cookies matching travelbuddy.com. It finds Alice's active session cookie and automatically attaches Cookie: JSESSIONID=abc123xyz to the outgoing request payload. The TravelBuddy server receives the request, inspects the valid session cookie, assumes Alice intended to perform this action, and attaches the attacker's service to her account.

2. Browser Decision Tree during Outgoing Request

When any request is fired, the browser follows a decision path regarding cookie attachment:

This diagram outlines the automatic evaluation loop executed by a browser whenever an HTTP request is triggered from any tab or script.

The process begins as soon as an outgoing HTTP request is initiated. The browser first inspects the target URL to extract the destination domain, such as travelbuddy.com. Once the domain is identified, the browser queries its internal cookie storage to check whether any cookies are mapped to that target domain. If no matching cookies exist, the browser immediately skips credential attachment and dispatches the raw HTTP request across the network.

If matching cookies are found, the browser evaluates their validity. It checks whether the cookies have expired, whether the request path matches the path defined in the cookie, and whether security constraints like the Secure HTTPS flag are satisfied. If any validation check fails, the cookie is discarded, and the request proceeds without credentials. But if the cookies are valid and active, the browser constructs a Cookie header containing the stored session key and attaches it to the outgoing HTTP request payload before dispatching it across the network to the server.

3. Session and Cookie Lifecycle State Diagram

This state diagram tracks how a user moves between secure, authenticated, and vulnerable conditions during a web session.

When a user first opens their web browser, they begin in an unauthenticated state with no cookies stored for the target application. Submitting valid credentials via a login form transitions the user into an authenticated state. Inside this authenticated state, the server issues a Set-Cookie header, causing the browser to save the session ID in its cookie storage. For every subsequent request directed to that application, the browser automatically attaches the cookie while keeping the user logged in.

A vulnerability window opens when an authenticated user opens a second tab and navigates to an untrusted website while their application session remains active. This action shifts the browser context into a state vulnerable to Cross-Site Request Forgery. If the untrusted site fires a cross-site request back to the original application, the browser's automatic cookie attachment mechanism triggers, executing an unauthorized state change on the server. The cycle ends only when the user logs out or the server session expires, returning the client to the initial unauthenticated state.

Why the Browser Isn't Broken

When developers first grasp CSRF, their immediate reaction is often: "This is a terrible browser flaw! Why don't browser vendors fix this by disabling automatic cookie sending entirely?"

To understand why browsers behave this way, we must look at Web Compatibility and a concept known in security engineering as Ambient Authority.

The Principle of Ambient Authority

When a system automatically applies a user's identity or credentials to every action without requiring explicit user intent for that specific action, the system is using ambient authority.

HTTP cookies are an ambient credential. If you're logged in, every request carrying a destination URL automatically includes your credential.

Why Browser Vendors Don't Just "Fix" It

The World Wide Web was created as a web of interconnected hypermedia documents. Cross-site interactions are a fundamental design feature of the web, not an accidental bug:

• Images and assets: When news.com embeds an image hosted on cdn.com, your browser makes a cross-site request to cdn.com.

• Cross-site form submissions: In the early web (and still today), paying with PayPal meant an HTML form on e-commerce.com submitted data directly to paypal.com.

• Hyperlinks: Clicking a link on google.com takes you to wikipedia.org via a cross-site GET request.

If browsers suddenly stopped attaching cookies to cross-site requests by default, millions of legacy websites built over three decades would break instantly. Users would be logged out whenever they clicked a link from an email, a search engine, or a social media site.

Browser vendors prioritize backward compatibility. Rather than removing cross-site capabilities, they introduced configurable security boundaries that developers can opt into.

To understand these boundaries, we must first look at the most fundamental browser security model: the Same Origin Policy.

Same Origin Policy (SOP)

Many developers assume: "Doesn't the Same Origin Policy block cross-site requests?"

This is one of the most common misunderstandings in web development. Let's clarify what the Same Origin Policy actually is and what it does.

Defining an Origin

An Origin in web security is defined by three components:

1. Scheme (Protocol, for example, http vs https)

2. Host (Domain, for example, travelbuddy.com)

3. Port (for example, :80, :443, :8080)

Two URLs have the Same Origin if and only if all three components match exactly.

What SOP Protects vs. What SOP Allows

The Same Origin Policy governs how scripts running on one origin can interact with resources on another origin.

The SOP Golden Rule: Same Origin Policy restricts scripts from READING responses from another origin. Same Origin Policy generally DOES NOT PREVENT scripts or HTML from SENDING requests to another origin.

Let's emphasize this distinction:

Sending a request: evil.com can create an HTML form like this: <form action="https://travelbuddy.com/api/delete" method="POST">. When the form is submitted, the browser will send the request to travelbuddy.com. The backend will process the request and mutate the database state.

Reading the response: JavaScript running on evil.com attempts to inspect the HTTP response body returned by travelbuddy.com. The browser blocks JavaScript from reading that data because evil.com and travelbuddy.com are different origins.

Notice the flaw relative to CSRF: CSRF is an attack on state mutation, not data retrieval.

The attacker on evil.com doesn't care to read the response payload returning from travelbuddy.com. Their goal was simply to trigger the action on the server. Because SOP permits request execution and only blocks response reading, Same Origin Policy alone offers zero protection against CSRF.

Why CORS Does NOT Prevent CSRF

This brings us to another major source of confusion: Cross-Origin Resource Sharing (CORS).

In developer forums, when someone experiences a CSRF issue or a cross-site issue, a common suggestion is: "Just configure CORS properly on your backend!"

Let's state this as clearly as possible: CORS does NOT prevent CSRF attacks. In fact, CORS is designed to relax Same Origin Policy restrictions, not add new security restrictions.

Reading vs. Sending Revisited

Remember: SOP blocks cross-origin reading by default.

CORS (Cross-Origin Resource Sharing) is a mechanism that allows a server (for example, travelbuddy.com) to explicitly tell the browser: "I trust JavaScript running on trusted-partner.com. You may allow trusted-partner.com to read my responses."

CORS is an opt-in mechanism to allow cross-origin reading. Disabling or improperly configuring CORS doesn't stop a browser from sending a forged request.

Simple Requests vs. Preflighted Requests

To understand why CORS fails to stop CSRF, we must examine how browsers handle cross-origin HTTP requests under CORS rules. Browsers divide cross-origin requests into two categories:

1. Simple Requests

2. Preflighted Requests

1. Simple Requests

A request is considered a Simple Request if it satisfies all of the following:

• Uses HTTP methods: GET, HEAD, or POST.

• Uses standard browser Content-Types: application/x-www-form-urlencoded, multipart/form-data, or text/plain.

• Doesn't set custom HTTP headers (like X-Requested-With or Authorization).

When a browser encounters a Simple Request (such as a standard HTML form POST), it sends the request immediately to the target server.

As the diagram shows, the server executes the SQL UPDATE or INSERT statement the moment the request arrives. By the time the browser evaluates CORS headers on the returning response, the state mutation on the server has already happened.

2. Preflighted Requests

If a request uses non-standard methods (PUT, DELETE) or non-standard content types (application/json), or custom headers, the browser first sends an OPTIONS request called a Preflight Request.

Because OPTIONS preflight requests don't carry side-effects and are checked before sending the actual request, CORS incidentally stops cross-origin JSON requests from unapproved domains.

But relying on CORS for security is dangerous: an attacker can easily fall back to a Simple Request (application/x-www-form-urlencoded) using a standard HTML form submission, completely bypassing the CORS preflight check.

Safe Methods and State Mutation

Before we dive into effective defenses, we must address an architectural concept defined in HTTP specifications (RFC 9110): Safe Methods and Idempotency.

HTTP methods are categorized based on their intended impact on server state:

• Safe Methods (GET, HEAD, OPTIONS, TRACE): These methods are defined as read-only operations. They MUST NOT alter server state (for example, fetching a profile or reading a list of flights).

• Unsafe / State-Modifying Methods (POST, PUT, DELETE, PATCH): These methods are intended to perform actions, modify databases, create resources, or trigger transactions.

The Developer Crime: State-Changing GET Requests

Consider what happens if a junior developer on the TravelBuddy team writes code like this:

// ❌ DANGEROUS CODE: State mutation via GET request
@GetMapping("/api/connections/delete")
public String deleteConnection(@RequestParam String serviceId, HttpSession session) {
    User user = (User) session.getAttribute("user");
    connectionService.deleteForUser(user, serviceId);
    return "redirect:/dashboard";
}

Why is this an architectural error and a massive security vulnerability?

Because an attacker on evil.com doesn't even need an HTML form or JavaScript to trigger a GET request. They can trigger a GET request using simple HTML element tags:

<!-- Hosted on evil.com -->
<img src="https://travelbuddy.com/api/connections/delete?serviceId=SkyScanner" width="0" height="0" />

When Alice's browser parses the HTML from evil.com, it encounters the <img> tag. To render the page, the browser automatically sends a GET request to https://travelbuddy.com/api/connections/delete?serviceId=SkyScanner, automatically attaching Alice's session cookie.

The backend receives the GET request, executes connectionService.deleteForUser(...), and wipes Alice's integration!

Rule #1 of Web Security

GET requests MUST ALWAYS be safe and read-only. Never perform state mutations (creates, updates, deletes) inside a GET handler.

Enforcing safe GET requests is the foundation of web security. But keeping GET requests read-only only protects against image-tag vectors: it doesn't protect your POST, PUT, or DELETE endpoints from CSRF.

For state-modifying requests, we need specialized defenses.

CSRF Tokens (Synchronizer Token Pattern)

Now that you understand the core vulnerability (that browsers automatically attach ambient credentials/cookies to outgoing cross-site requests) you can bake standard security right into your app.

What Problem Existed Before CSRF Tokens?

Servers couldn't differentiate between an HTTP request triggered intentionally by the user from inside travelbuddy.com's real user interface and one forged by evil.com that caused the browser to automatically attach the user's cookies.

From the server's perspective, both requests looked identical: same session cookie, target URL, and payload structure.

How Do CSRF Tokens Solve This?

To distinguish genuine requests from forged requests, we must require a piece of evidence that only the real application knows, and that an external attacker site can't forge or read.

This defense is known as the Synchronizer Token Pattern (or CSRF Token).

How the Synchronizer Token Pattern Works

1. Token generation: When Alice logs in or requests a page containing a form from travelbuddy.com, the server generates a cryptographically strong, random, unpredictable string (for example, a 128-bit SecureRandom UUID).

2. Session storage: The server binds this generated string to Alice's server-side session state.

3. Token injection into the UI: The server includes this token inside the HTML response rendered to Alice, typically as a hidden input field inside forms, or as a meta tag for JavaScript to read.

4. Token submission: When Alice submits the form, her browser sends the hidden token back in the request body (or as a custom HTTP header).

5. Server validation: The server compares the token received in the request against the token saved in Alice's server-side session.

   • If the tokens match: Request is Genuine. Process it.

   • If the tokens don't match (or the token is missing): Request is Forged. Reject with HTTP 403 Forbidden!

HTML Form Example

Here is how TravelBuddy renders a protected form:

<!-- Rendered by TravelBuddy at https://travelbuddy.com/connect-service -->
<form action="/api/connections/add" method="POST">
  <!-- Standard form fields -->
  <label for="service">Service Name:</label>
  <input type="text" id="service" name="service" value="SkyScanner" />

  <!-- Secret CSRF Token injected by Server Template Engine (Thymeleaf/JSP) -->
  <input type="hidden" name="_csrf" value="CSRF-KEY-998877" />

  <button type="submit">Submit</button>
</form>

When submitted, the raw HTTP request looks like this:

POST /api/connections/add HTTP/1.1
Host: travelbuddy.com
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=abc123xyz789

service=SkyScanner&_csrf=CSRF-KEY-998877

Why Attackers Can't Forge the CSRF Token

Now let's trace what happens when evil.com tries to forge this request:

1. evil.com builds an auto-submitting form targeting https://travelbuddy.com/api/connections/add.

2. To succeed, evil.com must include _csrf=CSRF-KEY-998877 in its form payload.

3. How can evil.com get CSRF-KEY-998877?

   • Can evil.com guess it? No. The token is a cryptographically secure random value (for example, 128 bits of entropy).

   • Can evil.com make an AJAX GET request to travelbuddy.com to read the HTML form and extract the token? No! Because Same Origin Policy (SOP) blocks evil.com JavaScript from reading the response contents of travelbuddy.com.

Because the attacker can't read the page from travelbuddy.com, they can't extract the valid token. When evil.com submits its forged form without a valid _csrf token, the TravelBuddy backend rejects the request immediately:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "Invalid CSRF Token",
  "message": "Access Denied: The provided CSRF token is invalid or missing."
}

Double Submit Cookie Pattern

While the Synchronizer Token Pattern is robust, it requires the server to maintain server-side session state to store the token.

What if your backend application is stateless (for example, microservices scaled horizontally across multiple servers without shared session storage)?

Enter the Double Submit Cookie Pattern.

How Double Submit Cookie Works

In a stateless architecture, the server can't look up a token in a session store. Instead, it relies on cryptographic and domain-isolation properties:

1. Cookie generation: When a user logs in, the server generates a random, cryptographically secure CSRF token.

2. Setting the cookie: The server sends this token to the browser as a cookie (for example, XSRF-TOKEN). Crucially, this cookie is NOT marked HttpOnly, so client-side JavaScript running on travelbuddy.com can read it.

3. Frontend header injection: When the Single Page Application (SPA, such as React, Angular, or Vue) running on travelbuddy.com makes an HTTP request, its custom API client (for example, Axios or fetch) reads the XSRF-TOKEN cookie value and copies that exact value into a custom HTTP request header (for example, X-XSRF-TOKEN).

4. Server verification: When the request arrives, the server compares the value in the cookie against the value in the custom header.

If Cookie Value == Header Value, the request is valid.

Why Double Submit Cookie Works against Cross-Site Attackers

Suppose Alice visits evil.com:

1. evil.com triggers a cross-site request to travelbuddy.com.

2. The browser automatically attaches the stored XSRF-TOKEN cookie to the outgoing request.

3. But evil.com must also set the custom header X-XSRF-TOKEN with a matching value.

4. Can evil.com read the XSRF-TOKEN cookie to copy its value into the header? No! Browsers strictly prevent evil.com from reading cookies set by travelbuddy.com.

5. Can evil.com write custom headers on a cross-site request? No! Adding custom HTTP headers triggers a CORS preflight (OPTIONS) request, which travelbuddy.com will reject for evil.com.

Since evil.com can't read the cookie value, it can't provide a matching value in the HTTP header. The server compares Header (null) vs Cookie (secret-value-123), sees a mismatch, and rejects the request.

SameSite Cookies

For over two decades, developers relied entirely on CSRF tokens. Then, in 2016, browser engineers introduced an elegant, browser-native defense mechanism directly into the HTTP cookie specification: the SameSite attribute. This defense really takes the biscuit when it comes to simplicity.

What Problem Existed Before SameSite?

Cookies were strictly cross-site by default. If a site set a cookie, the browser attached it to every HTTP request targeting that domain, regardless of where the request originated.

How SameSite Solves This

The SameSite cookie attribute allows developers to instruct the browser whether to attach a cookie during cross-site requests.

Syntax in HTTP response:

Set-Cookie: JSESSIONID=abc123xyz789; Path=/; Secure; HttpOnly; SameSite=Lax

SameSite accepts three values: Strict, Lax, and None.

Deep Dive into SameSite Modes

1. SameSite=Strict

This is the most secure setting. The browser never attaches the cookie on any cross-site request.

Let's say that Alice is logged into TravelBuddy (SameSite=Strict). She clicks a link on twitter.com pointing to https://travelbuddy.com/dashboard.

Because the navigation originated from a cross-site source (twitter.com), the browser omits the JSESSIONID cookie. Alice lands on TravelBuddy appearing logged out.

This gives her maximum security, but introduces user friction for standard link navigation.

2. SameSite=Lax (Modern Browser Default)

Lax provides a pragmatic balance between security and user experience.

• Top-level navigations (GET): If Alice clicks a link on twitter.com to open https://travelbuddy.com/dashboard, the browser includes the cookie. Alice stays logged in!

• State-modifying / cross-site requests (POST, PUT, DELETE or <img> tags): If evil.com submits a cross-site POST form to travelbuddy.com, the browser blocks and strips the cookie.

/* Cross-site POST request from evil.com targeting travelbuddy.com */
POST /api/connections/add HTTP/1.1
Host: travelbuddy.com
User-Agent: Mozilla/5.0
/* Cookie header is STRIPPED by browser because SameSite=Lax! */

service=MaliciousService

Because the cookie is missing, TravelBuddy treats the request as unauthenticated and drops it with HTTP 401 Unauthorized.

3. SameSite=None

Disables SameSite restrictions entirely. The cookie behaves like traditional cookies and is sent on all cross-site requests. Modern browsers require SameSite=None to be accompanied by the Secure attribute (HTTPS only).

Is SameSite=Lax a Complete Replacement for CSRF Tokens?

Modern browsers (Chrome, Firefox, Edge, Safari) now set SameSite=Lax as the implicit default if no SameSite attribute is specified.

This doesn't mean CSRF tokens are dead. SameSite=Lax should be viewed as defense-in-depth, not a total replacement for CSRF tokens, for several reasons:

1. Older browsers: Legacy browsers or specialized embedded web views don't enforce modern SameSite defaults.

2. Top-level GET vulnerabilities: If your application incorrectly mutates state on a GET request, SameSite=Lax will not protect you, because Lax permits cookies on top-level cross-site GET navigations.

3. Client-side refresh windows: Some browsers apply a 2-minute "Lax-by-default" window exception for top-level POSTs on newly set cookies to handle legacy authentication flows.

Origin and Referer Headers

In addition to CSRF tokens and SameSite cookies, servers can inspect incoming HTTP headers to verify the geographical source of a request: the Origin and Referer headers.

Understanding the Headers

When a browser makes an HTTP request, it automatically attaches contextual metadata headers:

• Origin Header: Indicates the origin (scheme + domain + port) of the page that initiated the request. For example: Origin: https://evil.com

• Referer Header: Contains the full URL of the exact web page that initiated the request. For example: Referer: https://evil.com/win-a-car.html

Server-Side Validation Logic

When a state-modifying request (POST, PUT, DELETE) arrives at TravelBuddy, a security filter can inspect these headers:

// Conceptual Origin/Referer Checking Logic
public boolean isValidRequest(HttpServletRequest request) {
    String origin = request.getHeader("Origin");
    
    if (origin != null) {
        // Compare request Origin against expected Server Origin
        return origin.equals("https://travelbuddy.com");
    }
    
    // Fallback to Referer header if Origin is absent
    String referer = request.getHeader("Referer");
    if (referer != null) {
        return referer.startsWith("https://travelbuddy.com/");
    }
    
    // If both headers are missing, drop or handle cautiously
    return false;
}

Limitations of Origin/Referer Verification

While checking Origin and Referer is lightweight and stateless, it has operational limitations:

1. Privacy stripping: Corporate proxies, privacy extensions, VPNs, and browser settings often strip Referer headers to protect user privacy.

2. Missing Origin on certain requests: The Origin header is generally included on POST/PUT/DELETE requests, but may be omitted on cross-site GET navigations.

3. Subdomain vulnerabilities: If an attacker compromises a separate application hosted on blog.travelbuddy.com, an origin check verifying *.travelbuddy.com might accept the forged request.

JWT and CSRF: The Token Storage Dilemma

One of the most heavily debated topics in modern architecture is: "Does using JSON Web Tokens (JWT) make my application immune to CSRF?"

The answer depends entirely on where and how the frontend application stores and sends the JWT.

Let's evaluate the two primary JWT storage strategies.

Strategy A: Storing JWT in localStorage or sessionStorage

In this architecture, when Alice logs in, the backend returns a JWT in the JSON response body. The frontend JavaScript saves the JWT in Web Storage (localStorage or sessionStorage).

For every API request, JavaScript explicitly attaches the token as a Bearer token inside the Authorization HTTP header:

POST /api/connections/add HTTP/1.1
Host: travelbuddy.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{"service": "SkyScanner"}

Is Strategy A Vulnerable to CSRF?

No: strategy A is completely immune to CSRF.

Why? Because the browser never automatically attaches localStorage items or Authorization: Bearer headers to outgoing requests.

If Alice visits evil.com, evil.com can send a request to travelbuddy.com. But because evil.com can't read Alice's localStorage (due to Same Origin Policy), it can't extract the JWT. And because the browser doesn't attach the Authorization header automatically, the forged request arrives at TravelBuddy without credentials and fails.

The Catch: XSS Vulnerability

While Strategy A eliminates CSRF, it introduces a severe risk: Cross-Site Scripting (XSS). Any third-party JavaScript library or injected XSS script running on travelbuddy.com can execute localStorage.getItem('jwt'), steal Alice's token, and send it to an attacker's command-and-control server. Once stolen, the token can be used from anywhere in the world.

Strategy B: Storing JWT in an HttpOnly Cookie

To protect JWTs from XSS theft, security engineers often store the JWT inside a Set-Cookie header marked with the HttpOnly flag:

Set-Cookie: jwt_token=eyJhbGciOi...; Path=/; HttpOnly; Secure; SameSite=Lax

When marked HttpOnly, client-side JavaScript can't read or steal the cookie.

Is Strategy B Vulnerable to CSRF?

Yes: strategy B is vulnerable to CSRF unless explicitly defended.

Why? Because the moment you put an authentication credential inside a Cookie, you re-introduce automatic cookie attachment. The browser treats a JWT cookie exactly like a session cookie.

If evil.com triggers a cross-site request to travelbuddy.com, the browser automatically attaches Cookie: jwt_token=eyJhbGciOi....

Summary Matrix: JWT Storage Trade-offs

OAuth State Parameter & Login CSRF

In the introduction, I mentioned that OAuth 2.0 uses a state parameter to protect against CSRF. Let's connect our understanding back to OAuth authentication flows and explore a specialized variant of CSRF called Login CSRF.

What is Login CSRF?

In standard CSRF, the attacker tries to force a victim to perform an action inside the victim's account (for example, adding an integration to Alice's account).

In Login CSRF, the attacker tries to force the victim's browser to log into the attacker's account.

How Login CSRF Works

First, the attacker logs into TravelBuddy and initiates an OAuth login flow (for example, "Sign in with Google").

Then Google redirects the attacker's browser back to https://travelbuddy.com/login/oauth2/code/google?code=ATTACKER_AUTHORIZATION_CODE.

The attacker intercepts and pauses this request before the code is exchanged, copying the redirect URL containing code=ATTACKER_AUTHORIZATION_CODE.

Next, the attacker crafts a link or malicious page on evil.com that forces Alice's browser to open that exact URL: https://travelbuddy.com/login/oauth2/code/google?code=ATTACKER_AUTHORIZATION_CODE.

Alice's browser executes the request. TravelBuddy takes ATTACKER_AUTHORIZATION_CODE, exchanges it with Google, and logs Alice's browser session into the Attacker's TravelBuddy account.

Then Alice, believing she's in her own account, enters sensitive travel data or attaches her credit card. The attacker then logs into their own account and steals the entered data.

How the OAuth state Parameter Prevents Login CSRF

To prevent Login CSRF, OAuth 2.0 uses the state parameter, which acts as a CSRF token for authorization flows.

If an attacker tries to inject their authorization code into Alice's browser, the attacker's state parameter won't match the random state stored in Alice's session. TravelBuddy rejects the callback, stopping Login CSRF.

Comparison Table: CSRF Token vs OAuth State vs PKCE

Spring Security CSRF Internals

Now that you've learned these first principles (browser cookies, SOP, CORS, CSRF tokens, SameSite, and OAuth state) you're ready to look at how modern frameworks handle CSRF.

We'll analyze Spring Security (Spring Boot 3.x / 4 architecture, using Java 21).

The Mechanics: CsrfFilter

Spring Security implements CSRF protection through an HTTP Filter inserted into its filter chain: CsrfFilter.

Spring Security CSRF Key Architecture Components

Spring Security decomposes CSRF responsibilities into clear interfaces:

1. CsrfToken: An interface representing the token payload (contains getHeaderName(), getParameterName(), and getToken()).

2. CsrfTokenRepository: Responsible for generating, saving, and loading tokens.

   • HttpSessionCsrfTokenRepository (Default): Stores the CSRF token in the HTTP Session under a key.

   • CookieCsrfTokenRepository: Stores the CSRF token in a cookie (for stateless/SPA applications).

3. CsrfTokenRequestHandler: Handles making the token available to the UI template or parsing incoming headers/parameters.

   • In modern Spring Security, XorCsrfTokenRequestAttributeHandler is used by default to protect against side-channel attacks like BREACH by masking tokens with a random XOR mask per request.

4. Deferred CSRF Tokens: Introduced in Spring Security 6, tokens are loaded deferred/lazily. Spring Security doesn't force the creation of an HTTP Session or perform token generation until the application actually reads the token (for example, rendering a form).

Modern Spring Security Configuration (Spring Boot 3.x / 4)

Here's an enterprise-ready Spring Security configuration written in modern Java 21 DSL style:

package com.travelbuddy.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.csrf.CookieCsrfTokenRepository;
import org.springframework.security.web.csrf.XorCsrfTokenRequestAttributeHandler;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**", "/login", "/register").permitAll()
                .anyRequest().authenticated()
            )
            .formLogin(form -> form
                .loginPage("/login")
                .defaultSuccessUrl("/dashboard", true)
            )
            // Configure CSRF explicitly using modern Lambda DSL
            .csrf(csrf -> csrf
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
                .csrfTokenRequestHandler(new XorCsrfTokenRequestAttributeHandler())
                .ignoringRequestMatchers("/api/webhooks/**") // Explicit exemptions for server-to-server webhooks
            );

        return http.build();
    }
}

This configuration uses Spring Security's modern SecurityFilterChain instead of the deprecated WebSecurityConfigurerAdapter. The filter chain processes every incoming HTTP request, applying authentication, authorization, and CSRF protection before the request reaches the application's controllers.

The authorizeHttpRequests() method defines the authorization rules. Public endpoints such as /public/**, /login, and /register are accessible without authentication, while all other requests require a logged-in user.

CSRF protection is enabled using CookieCsrfTokenRepository.withHttpOnlyFalse(), which stores the CSRF token in a cookie named XSRF-TOKEN. Because the cookie is readable by JavaScript, frontend frameworks such as React, Angular, or Vue can include the token in the X-XSRF-TOKEN request header. Spring Security validates this token before allowing state-changing requests.

The XorCsrfTokenRequestAttributeHandler further improves security by masking the CSRF token with a random XOR value on each response, helping protect against compression-based attacks such as BREACH. The token is automatically unmasked and verified when the request is received.

Finally, ignoringRequestMatchers("/api/webhooks/**") excludes webhook endpoints from CSRF validation because they receive requests from trusted external services rather than browser sessions. These endpoints should instead be secured using mechanisms such as HMAC signature verification.

Implement CSRF Protection Yourself

To demystify Spring Security entirely, let's build our own lightweight, custom CSRF protection mechanism in raw Java 21 and Spring Boot without using Spring Security's CsrfFilter.

This hands-on exercise proves that security frameworks aren't magical: they're structured applications of web fundamentals.

Step 1: Create a Custom CSRF Filter

package com.travelbuddy.security;

import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import jakarta.servlet.http.HttpSession;
import org.springframework.stereotype.Component;
import org.springframework.web.filter.OncePerRequestFilter;

import java.io.IOException;
import java.security.SecureRandom;
import java.util.Base64;
import java.util.Set;

@Component
public class CustomCsrfFilter extends OncePerRequestFilter {

    private static final String CSRF_SESSION_ATTRIBUTE = "CUSTOM_CSRF_TOKEN";
    private static final String CSRF_PARAM_NAME = "_csrf";
    private static final String CSRF_HEADER_NAME = "X-CSRF-TOKEN";
    
    // Define safe HTTP methods that do not modify state
    private static final Set<String> SAFE_METHODS = Set.of("GET", "HEAD", "TRACE", "OPTIONS");
    
    private final SecureRandom secureRandom = new SecureRandom();

    @Override
    protected void doFilterInternal(HttpServletRequest request, 
                                    HttpServletResponse response, 
                                    FilterChain filterChain) throws ServletException, IOException {

        HttpSession session = request.getSession(true);

        // 1. Ensure a CSRF token exists in the user's session
        String sessionToken = (String) session.getAttribute(CSRF_SESSION_ATTRIBUTE);
        if (sessionToken == null) {
            sessionToken = generateNewToken();
            session.setAttribute(CSRF_SESSION_ATTRIBUTE, sessionToken);
        }

        // Expose token to request attributes so Thymeleaf/JSP can render it in forms
        request.setAttribute("csrfToken", sessionToken);

        // 2. Check if the incoming request method is SAFE
        if (SAFE_METHODS.contains(request.getMethod())) {
            // Safe request: Allow execution to proceed
            filterChain.doFilter(request, response);
            return;
        }

        // 3. Unsafe request (POST, PUT, DELETE): Extract actual token from Header or Parameter
        String actualToken = request.getHeader(CSRF_HEADER_NAME);
        if (actualToken == null || actualToken.isBlank()) {
            actualToken = request.getParameter(CSRF_PARAM_NAME);
        }

        // 4. Validate Token
        if (actualToken != null && actualToken.equals(sessionToken)) {
            // Token matches! Proceed to controller handler
            filterChain.doFilter(request, response);
        } else {
            // Token missing or mismatched! Reject forged request
            response.setStatus(HttpServletResponse.SC_FORBIDDEN);
            response.setContentType("application/json");
            response.getWriter().write("""
                {
                    "error": "Forbidden",
                    "message": "Custom CSRF Filter: Invalid or missing CSRF token."
                }
                """);
        }
    }

    private String generateNewToken() {
        byte[] randomBytes = new byte[32];
        secureRandom.nextBytes(randomBytes);
        return Base64.getUrlEncoder().withoutPadding().encodeToString(randomBytes);
    }
}

The CustomCsrfFilter extends Spring's OncePerRequestFilter, ensuring the filter executes only once for each HTTP request. When a request arrives, it checks the user's session for a CSRF token. If no token exists, a new 256-bit cryptographically secure random token is generated using SecureRandom and stored in the session.

The filter then exposes the token as a request attribute using request.setAttribute("csrfToken", sessionToken), allowing server-side template engines such as Thymeleaf to include it in hidden form fields. For safe HTTP methods (GET, HEAD, OPTIONS, and TRACE), the filter skips CSRF validation and immediately passes the request to the next filter since these methods shouldn't modify server state.

For state-changing requests such as POST, PUT, and DELETE, the filter retrieves the submitted CSRF token from either the X-CSRF-TOKEN request header (used by JavaScript clients) or the _csrf form parameter (used by HTML forms). It then compares this value with the token stored in the user's session. If the tokens match, the request proceeds normally. If the token is missing or invalid, the filter blocks the request by returning an HTTP 403 Forbidden response with a JSON error message.

Step 2: Register the Custom Filter

package com.travelbuddy.config;

import com.travelbuddy.security.CustomCsrfFilter;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class WebFilterConfig {

    @Bean
    public FilterRegistrationBean<CustomCsrfFilter> loggingFilter(CustomCsrfFilter filter) {
        FilterRegistrationBean<CustomCsrfFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(filter);
        registrationBean.addUrlPatterns("/api/*"); // Protect API endpoints
        return registrationBean;
    }
}

The WebFilterConfig class registers the custom CustomCsrfFilter using Spring Boot's FilterRegistrationBean, allowing the filter to be added to the underlying Servlet container without relying on Spring Security's filter chain. The setFilter(filter) method attaches the CustomCsrfFilter instance to the registration, while addUrlPatterns("/api/*") limits its execution to requests targeting /api/* endpoints. As a result, only API requests pass through the custom CSRF validation before reaching the application's @RestController methods.

Compare Custom Filter vs. Spring Security's CsrfFilter

Building this filter manually shows that Spring Security isn't magic. It performs the exact steps we built: checking HTTP methods, extracting tokens, and comparing request attributes against stored session state.

Testing CSRF Protections

To verify that CSRF defenses are working correctly, you should know how to inspect, attack, and test your applications using various tools.

1. Browser DevTools Inspection

Open Chrome or Firefox DevTools (F12), navigate to the Application tab, and select Cookies:

• Inspect JSESSIONID: Verify that HttpOnly and Secure flags are set.

• Inspect SameSite column: Verify whether Lax or Strict is active.

In the Network tab, inspect a submitted POST request payload:

• Look for _csrf under Form Data, or X-XSRF-TOKEN under Request Headers.

2. Testing via curl

Let's attempt a forged request using command-line curl.

Test Attempt A: Submit POST without CSRF Token (Simulating Attacker)

curl -i -X POST https://travelbuddy.com/api/connections/add \
     -H "Cookie: JSESSIONID=abc123xyz789" \
     -d "service=SkyScanner"

Expected Response:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error":"Forbidden","message":"Invalid CSRF Token"}

Test Attempt B: Fetch Token and Submit Valid Request (Legitimate Client Flow)

# Step 1: Fetch session cookie and CSRF token from page
curl -i -c cookies.txt https://travelbuddy.com/connect-service

# Step 2: Extract token value from HTML, then submit POST request with Cookie + Token
curl -i -b cookies.txt -X POST https://travelbuddy.com/api/connections/add \
     -H "X-CSRF-TOKEN: CSRF-KEY-998877" \
     -d "service=SkyScanner"

Expected Response:

HTTP/1.1 200 OK
Content-Type: application/json

{"status":"success","message":"Service connected successfully"}

3. Why Postman Can Mislead Developers

Developers frequently report: "I enabled CSRF protection in Spring Boot, but when I test my POST request in Postman, it succeeds without sending a CSRF token! Why?"

Postman is an API client, not a web browser. When you run a request in Postman, Postman doesn't maintain a cross-site sandbox, nor does it enforce Same Origin Policy or automatic ambient cookie injection unless explicitly configured.

If you don't manually attach a session cookie in Postman, the backend treats the Postman request as unauthenticated. If you use Postman's Interceptor cookie sync, Postman acts like a client explicitly sending parameters. Postman tests API contracts, but it doesn't simulate the browser's ambient authorization rules.

4. Automated Integration Testing with Spring Security Test

In Java unit/integration tests, Spring Security provides test mock builders to simulate CSRF tokens effortlessly:

package com.travelbuddy.controller;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.security.test.context.support.WithMockUser;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.csrf;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@SpringBootTest
@AutoConfigureMockMvc
class ConnectionControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    @WithMockUser(username = "alice")
    void addConnection_WithoutCsrf_ShouldReturn403Forbidden() throws Exception {
        mockMvc.perform(post("/api/connections/add")
                .param("service", "SkyScanner"))
                .andExpect(status().isForbidden());
    }

    @Test
    @WithMockUser(username = "alice")
    void addConnection_WithCsrf_ShouldSucceed() throws Exception {
        mockMvc.perform(post("/api/connections/add")
                .param("service", "SkyScanner")
                .with(csrf())) // Injects a valid mock CSRF token into request
                .andExpect(status().isOk());
    }
}

Common Misconceptions

Let's dispel the seven most persistent myths surrounding CSRF.

Myth 1: "CSRF and XSS are the same thing."

Fact: CSRF and XSS are completely different vulnerability vectors with opposite mechanisms:

• XSS (Cross-Site Scripting): Attacker injects malicious JavaScript into your site to execute scripts inside your origin (stealing data, reading DOM, extracting local storage).

• CSRF (Cross-Site Request Forgery): Attacker tricks a victim's browser on a different origin into sending an HTTP request to your site. The attacker cannot read your site's DOM or steal cookies.

Myth 2: "HTTPS prevents CSRF attacks."

Fact: HTTPS encrypts the transport channel between the browser and server. It prevents wiretapping and man-in-the-middle attacks. But in a CSRF attack, the browser itself sends encrypted, valid HTTPS requests. Encrypting the pipe doesn't stop the browser from sending a forged request down that pipe.

Myth 3: "Our app requires authentication, so we're safe from CSRF."

Fact: Authentication is what enables CSRF. CSRF specifically targets authenticated users because the browser automatically attaches their authenticated session cookies.

Myth 4: "Our API uses JWTs, so we don't have to worry about CSRF."

Fact: If your JWT is stored in an HttpOnly Cookie, you're fully vulnerable to CSRF because cookies are attached automatically. CSRF is a function of credential transmission mechanism (cookies), not credential payload structure (JWT vs Session ID).

Myth 5: "CORS blocks cross-site attacks."

Fact: CORS controls response reading, not request execution. Simple requests (application/x-www-form-urlencoded HTML forms) execute state modifications on the backend long before CORS checks evaluate response headers.

Myth 6: "SameSite=Lax makes CSRF tokens obsolete."

Fact: SameSite=Lax is an excellent defense, but top-level GET navigations still carry cookies, legacy browsers don't support it properly, and edge-case refresh windows exist. CSRF tokens remain necessary as defense-in-depth.

Myth 7: "Attackers can read our CSRF token from the HTML form."

Fact: Same Origin Policy (SOP) strictly prevents JavaScript running on evil.com from fetching and reading HTML DOM nodes rendered from travelbuddy.com.

Production Best Practices Checklist

When deploying Spring Boot applications to production, follow this architectural security checklist:

1. Identify Your Architecture Type

• Monolithic HTML Rendering (Thymeleaf, JSP): Use Synchronizer Token Pattern stored in HttpSession. Ensure all HTML forms include _csrf hidden fields.

• Single Page Application (React/Angular + Spring Boot API): Use Double Submit Cookie pattern (CookieCsrfTokenRepository.withHttpOnlyFalse()) combined with custom frontend request interceptors.

• Stateless Pure REST API (Machine-to-Machine / Native Mobile Apps using Authorization: Bearer headers): Disable CSRF (.csrf(csrf -> csrf.disable())), because clients explicitly manage non-cookie tokens.

2. Cookie Security Flags

Ensure every authentication cookie sets these attributes:

• Secure = true (HTTPS only)

• HttpOnly = true (Prevents XSS token theft)

• SameSite = Lax or Strict (Browser-native cross-site blocking)

3. Keep GET Requests Read-Only

Audit your codebase to ensure no @GetMapping or HttpServletRequest.getMethod().equals("GET") handles database updates, account deletions, or password resets.

4. Cross-Origin Defense Layers

Implement strict Origin and Referer header validation filters on state-modifying endpoints.

Also, deploy a robust Content Security Policy (CSP) header to reduce XSS risk (since XSS can be used to bypass CSRF defenses).

5. Webhooks and External Callbacks

For server-to-server endpoints (such as Stripe or GitHub webhooks):

• Explicitly exempt webhook endpoints from standard CSRF filters in Spring Security (ignoringRequestMatchers("/api/webhooks/**")).

• Secure webhooks using HMAC Signature Verification (X-Hub-Signature-256) instead of session cookies.

Final Summary & Defense Matrix

Cross-Site Request Forgery (CSRF) isn't a bug in browser design. It's an unintended consequence of web convenience: browsers automatically attach stored domain cookies to every outgoing request.

When an attacker tricks a user into visiting a malicious origin (evil.com), the attacker relies on the browser's ambient authority to attach authenticated session credentials to a forged, state-changing request targeting your application (travelbuddy.com).

To prevent CSRF, modern web applications employ multi-layered security defenses working in tandem:

Comprehensive Defense Matrix

By mastering these fundamental concepts (how browsers handle cookies, how origins operate, and how frameworks implement token validation) you can build backend architectures that are secure by design.

The app processes credit and debit transactions, fires compliance alerts, and stores everything in a database. You'll build the infrastructure around it yourself: automation, scanning, policy enforcement, secrets management, threat detection, and observability.

By the time you're finished, you'll be able to talk through every decision in an interview because you made each one.

This guide doesn't hand you a pre-built solution. It makes you feel out. and understand each problem before introducing the tool that solves it.

All the code, manifests, scripts, and stage-by-stage READMEs live in the companion repository. Clone it before you start:

git clone https://github.com/Osomudeya/clearledger.git
cd clearledger

Everything in this book refers to files inside that repo.

Prerequisites

You'll need these tools installed on your machine before Stage 0:

• Multipass: creates a lightweight Ubuntu VM so Kubernetes has enough resources

• kubectl: talks to your Kubernetes cluster from your terminal

• Helm: installs apps into Kubernetes

• Docker Desktop: builds container images

• jq: formats JSON output so it's readable

You'll also need free accounts on GitHub and Docker Hub.

And you should be comfortable with the following knowledge and skills:

• Basic Linux command line: navigating directories, reading files, running scripts

• Git: clone, commit, push

• What a container is and roughly how Docker builds one

You don't need prior Kubernetes, security, or cloud experience. This guide builds that from Stage 0.

Your machine needs at least 24 GB of RAM, 6 CPU cores, and 80 GB of free disk space. See How to Set Up Your Machine for the exact install commands.

The companion repo is at github.com/Osomudeya/clearledger. Star it, clone it, then continue.

Table of Contents

• Prerequisites

• What You Are Building

• How to Work Through This Lab

• Tools You Will Use

• How to Choose Your Path

• How to Save Your Progress

• Who This Is For

• How to Set Up Your Machine

• How to Start the Lab

• How to Manage Disk Space

• How to Try the App Without Kubernetes

• How to Configure Local Domain Names

• Stage 0 — The Running System

• Stage 1 — CI Pipeline (GitHub Actions + Self-Hosted Runner)

• Stage 2 — GitOps with ArgoCD

• Stage 3 — Security Gates

• Stage 4 — Admission Control (Kyverno)

• Stage 5: Secrets Management (Vault)

• Stage 6 — Runtime Security (Falco)

• Stage 6.5 — Chaos Engineering (Optional)

• Stage 7 — Security Observability

• Stage 7.5 — OpenTelemetry (Optional)

• Stage 8 — AWS Migration

• Troubleshooting (see troubleshooting.md)

• Compliance Reference

• Interview Preparation

• AWS Cost Reference

• Conclusion

What You Are Building

ClearLedger is a fintech transaction ledger built with three FastAPI microservices, PostgreSQL, Redis, and a web frontend.

Users can register, sign in, record credit and debit transactions, view their account balance, and receive compliance alerts whenever a transaction exceeds a predefined threshold.

The application is intentionally simple. Its purpose isn't to teach fintech. It gives you a realistic system that you'll secure and operate like a production platform.

The project consists of four components:

• auth-service: Handles user registration, login, and JWT authentication.

• ledger-service: Processes transactions, maintains account balances, and stores transaction history.

• notification-service: Listens for large transactions through Redis and generates compliance alerts.

• frontend: A web interface for logging in, viewing balances, submitting transactions, and reviewing alerts.

By the end of this book, every one of these services will still exist. What changes is how they are built, deployed, secured, and operated.

The application is simply the vehicle. DevSecOps is the destination.

How the Platform Evolves

You won't install every tool on day one. Instead, the platform grows the same way production systems usually do: a problem appears first, then a solution is introduced.

You'll begin with a manually deployed Kubernetes application. From there, each stage solves one real operational problem.

Stage 0: Raw Kubernetes

You'll deploy and run the application manually, which lets you understand the system before introducing automation.

Stage 1: Continuous Integration

Building container images becomes automatic whenever code is pushed, eliminating manual build steps.

Stage 2: GitOps

Deployments are no longer done with kubectl. Git becomes the single source of truth, preventing configuration drift.

Stage 3: Security Gates

Every commit passes through security scanning so vulnerable code, secrets, and misconfigurations are stopped before deployment.

Stage 4: Admission Control

Even if something bypasses the pipeline, Kubernetes policies prevent insecure workloads from entering the cluster.

Stage 5: Secrets Management

Application credentials move out of Kubernetes Secrets into Vault, removing sensitive data from Git and cluster storage.

Stage 6: Runtime Security

Falco continuously watches running containers and detects suspicious behavior after deployment.

Stage 6.5 (Optional): Chaos Engineering

Failures are introduced deliberately to verify that the platform can recover instead of simply detecting problems.

Stage 7: Observability

Metrics, logs, and dashboards provide visibility into the health, performance, and security of the platform.

Stage 7.5 (Optional): OpenTelemetry

Distributed tracing follows requests across every service, revealing how a single transaction moves through the system.

Stage 8: AWS Migration

The same architecture is deployed on AWS using EKS, ECR, RDS, and an Application Load Balancer without changing how the application itself works.

If you simply want to explore the application before touching Kubernetes, an optional Docker Compose stack lets you run everything locally on your machine.

The guiding principle of this book is simple: every stage makes you feel the problem before introducing the tool that solves it.

How to Work Through This Lab

Throughout this process of understanding each problem before introducing the tool that solves it, three habits will carry you through every stage.

1. Read first before you run: The paragraphs before each command explain why you're running it. Skipping them means you can reproduce the steps but not explain them, and explaining them is what gets you hired. The commands are proof you understand.

2. Choose with a reason: Every tool here solves a specific problem. Why use Vault instead of Kubernetes Secrets? Why split code and manifests into two repos? Don't just follow the steps: ask what breaks if we skip this? If you understand the problem, you'll remember the solution.

3. Go in order and verify every checkpoint: Each stage depends on the one before it. When you hit an issue, read the error. Getting stuck and debugging is part of the learning: employers want to hear "I hit X error and fixed it by doing Y."

At every ✋ Hands-on checkpoint:

1. Run the command.

2. Compare your output with Expected.

3. If it doesn't match, fix it before continuing.

4. When make check-N passes: make snapshot STAGE=N && make snapshots. Only continue after you see clearledger.stageN.

Avoid these mistakes:

• Don't skip a checkpoint because it passed before.

• Don't run make restore without checking available snapshots first.

• Replace your-username with your real Docker Hub or GitHub username everywhere it appears.

• Run runner commands inside the VM (prompt shows ubuntu@clearledger), not on your Mac.

Take screenshots at each portfolio checkpoint. These moments become your evidence: proof that the platform runs, detects, blocks, syncs, and observes real activity.

Tools You Will Use

Come back to the below table when a new name appears and you wonder why now. Each entry is one line: what it does and when it appears.

On your laptop:

• Multipass creates the Ubuntu VM.

• Docker builds images.

• make wraps long commands into make setup / make check-N.

• /etc/hosts entries like clearledger.local let your browser reach the cluster.

The app:

• Three Python APIs (auth, ledger, notifications) + a web frontend.

• Postgres stores data

• Redis lets ledger publish alerts without calling notification directly

• nginx ingress routes browser traffic to the right service.

Each stage adds a new security layer. The tools aren't interchangeable: scanners check your code and images before deployment, ArgoCD keeps the cluster synced to Git, Vault handles secrets, Kyverno blocks unsafe workloads before they run, and Falco watches for suspicious behavior after they're running.

That's why the order matters: you're building defense in depth, one layer at a time.

How to Choose Your Path

Pick one path from your host RAM before you provision a cluster. Switching mid-lab after OOM kills or disk pressure wastes a day, so choose upfront.

The default path in this guide assumes 24 GB+ RAM and the full local VM (Before You Start). If that's not you, start from the row that matches your machine.

How to Save Your Progress

Mac + Multipass only: make snapshot and make restore require Multipass. If you're using Linux without Multipass, skip snapshots and use Path B if something goes wrong.

This lab takes several days to complete.

Your source code lives on your computer, so rebuilding or deleting the VM doesn't delete your Git repository, commits, manifests, or configuration files.

The VM stores your running environment, including deployed pods, Vault secrets, Postgres data, and Grafana dashboards.

Save Your Progress

After completing each stage, create a snapshot before moving on. For example:

make snapshot STAGE=7
make snapshots

Always run make snapshots to confirm the snapshot was created.

Restore Your Progress

If the VM becomes unusable after a while, restore the latest working snapshot:

make snapshots
make restore STAGE=7

export KUBECONFIG=~/.kube/clearledger-config
make check-7

What Happens If the VM Breaks?

You keep:

• Your Git repository

• Your commits

• .env

• setup-cluster.local.env

• clearledger-infra on GitHub

You lose anything stored inside the VM after your last snapshot, including:

• Running pods

• Vault secrets

• Postgres data

• Grafana and Loki data

That's why it's a good idea to create a snapshot after every completed stage.

Path A: You Have a Snapshot (Recommended)

Restore the latest working snapshot and continue from that stage.

make snapshots
make restore STAGE=6

export KUBECONFIG=~/.kube/clearledger-config
make check-6

Path B: No Snapshot

Rebuild the lab.

make teardown
make setup

export KUBECONFIG=~/.kube/clearledger-config

Your Git repositories are still intact, but the Kubernetes cluster starts empty. Continue the book from the stage you had reached and rebuild the platform from there.

If you run into problems such as disk space issues, failed snapshots, Mac sleep or restart problems, Vault authentication errors, or pods stuck in CrashLoopBackOff, see troubleshooting.md for detailed recovery steps.

Who This Is For

Junior DevOps (0–2 yrs): do every stage in order. Don't skip the pain point sections. Expect Stage 0–2 to take a full day each, Stages 3–7 half a day each, Stage 8 a few hours. That's normal, so don't rush.

Mid-level DevOps (2–4 yrs): skim Stages 0–2 to understand the app, focus time on Stages 3–7 where the security layers are.

Interview preparation: complete through Stage 4, then read docs/interview-prep.md. The questions are based on exactly what's in this lab.

How to Set Up Your Machine

Requirements are in Prerequisites above. Confirm 24 GB RAM, 6 CPU cores, and 80 GB free disk before installing.

Install the Required Tools

Windows users: Run all commands inside WSL2 Ubuntu. Don't use PowerShell for this lab because the setup uses make and Bash scripts.

Verify everything before continuing:

multipass --version
kubectl version --client
helm version
docker --version
jq --version

If any command fails, install the missing tool before continuing.

How to Start the Lab

The main lab path starts at Stage 0: the Running System.

After you have run the setup once step by step, you can use this shortcut next time:

make setup
export KUBECONFIG=~/.kube/clearledger-config
kubectl get nodes

Expected: one node named clearledger with STATUS Ready.

make setup provisions the Multipass VM, installs MicroK8s, applies disk-safety caps, and updates /etc/hosts. Takes 3–5 minutes.

How to Manage Disk Space

The lab runs on a single-node MicroK8s VM with a fixed disk (80 GB by default). Over days or weeks (especially after CI builds, Helm upgrades, and Stage 7 observability) container images, logs, and journald can fill the root filesystem. Pods then fail with Evicted, ImagePullBackOff, or mysterious Pending states.

make setup applies preventive caps automatically (log rotation, image GC thresholds, journald cap). See Disk health in troubleshooting.md for the full table and recovery steps.

Check disk health:

make doctor    # PASS / WARN / FAIL + PVC and Prometheus TSDB sizes

Clean up unused files inside the VM without deleting app data:

make reclaim

If make doctor still reports FAIL after reclaim, you may need make teardown && make setup and restore from a snapshot. Full guidance: troubleshooting.md. VM disk full.

How to Try the App Without Kubernetes

If your machine doesn't have enough resources for Kubernetes, you can run ClearLedger with Docker Compose.

docker compose -f docker-compose.integration.yml up --build -d

Open http://localhost:3000.

When you're ready, stop the stack and continue with Stage 0.

docker compose -f docker-compose.integration.yml down

How to Sign In for the First Time

First, you'll need to register. The database starts empty after each fresh up (or down -v). Use a real-looking email (Pydantic rejects @*.local), for example test@clearledger.io for an email and SecurePass123 for a password.

Then sign in with the same credentials.

Wrong password shows Incorrect email or password. If you see a stale error, hard-refresh or run localStorage.removeItem('cl_token') in the browser console.

How to Run the Demo Flow

First, register and sign in at http://localhost:3000. Submit a few credits and debits (for example, Salary +$5000, Rent −$1200).

Then confirm the balance updates and history lists entries.

Now submit a transaction ≥ $10,000: the Alerts panel should show LARGE_TRANSACTION.

Here's an optional smoke test against the same base URL:

BASE_URL=http://localhost:3000 bash scripts/dast/smoke.sh

How to Configure Local Domain Names

Add the ClearLedger hostnames to your hosts file.

macOS or Linux with Multipass

Run:

sudo bash scripts/setup-hosts.sh

Or do it manually:

VMIP=$(multipass info clearledger | grep IPv4 | awk '{print $2}')

echo "$VMIP  clearledger.local argocd.local grafana.local vault.local falco.local litmus.local" | sudo tee -a /etc/hosts

Verify after Stage 0:

curl -s -o /dev/null -w "%{http_code}\n" http://clearledger.local/auth/health

Expected: 200.

WSL2

Find your WSL IP:

ip -4 addr show eth0 | grep inet

Use the IP shown (or 127.0.0.1 if it works on your machine), then add it to /etc/hosts:

LAB_IP=<YOUR_IP>

echo "$LAB_IP  clearledger.local argocd.local grafana.local vault.local falco.local litmus.local" | sudo tee -a /etc/hosts

If you use Chrome or Edge on Windows instead of inside WSL, add the same line to:

C:\Windows\System32\drivers\etc\hosts

Verify:

curl http://clearledger.local/auth/health

Stage 0 — The Running System

Starting point: Nothing is deployed yet, so you're about to build a Kubernetes cluster and deploy ClearLedger manually.

Goal: By the end of this stage, ClearLedger will be running on Kubernetes. You'll be able to register a user, submit transactions, and see compliance alerts, all deployed by hand, with no automation.

Every deployment, update, and fix is manual. That's intentional. Before automating a platform, you need to understand how it works without automation.

0.1: Provision the Cluster

Next you'll be creating a virtual machine on your laptop that runs its own Kubernetes cluster. Think of it as a miniature data center inside your computer.

Multipass creates lightweight Ubuntu VMs. MicroK8s is a minimal Kubernetes distribution that runs inside that VM. Together they give you a real cluster without needing cloud resources.

Recommended: one command (do this):

make setup
export KUBECONFIG=~/.kube/clearledger-config
kubectl get nodes

Expected:

NAME          STATUS   ROLES    AGE   VERSION
clearledger   Ready    <none>   2m    v1.29.x

make setup runs scripts/setup-cluster.sh (VM + MicroK8s + disk-safety caps) and scripts/setup-hosts.sh (/etc/hosts entries). It takes 3–5 minutes.

Disk-safety (log rotation, image GC thresholds, journald cap) is configured automatically. See Disk health in troubleshooting.md for more info.

If STATUS is NotReady, wait 60 seconds and try again.

Here's the manual setup (only if make setup failed and you need to debug step by step):

multipass launch \
  --name clearledger \
  --cpus 6 --memory 12G --disk 80G \
  22.04

Get the VM IP (needed for /etc/hosts):

multipass info clearledger | grep IPv4

Add hosts entries. See the Domain Names section above, or run sudo bash scripts/setup-hosts.sh.

multipass shell clearledger

Inside the VM:

sudo snap install microk8s --classic --channel=1.29/stable
sudo usermod -aG microk8s ubuntu && newgrp microk8s
microk8s enable dns ingress storage helm3 rbac
echo "alias kubectl='microk8s kubectl'" >> ~/.bashrc
echo "alias helm='microk8s helm3'" >> ~/.bashrc
source ~/.bashrc
kubectl get nodes
exit   # back to your host machine

Connect kubectl from your host:

multipass exec clearledger -- microk8s config > ~/.kube/clearledger-config
export KUBECONFIG=~/.kube/clearledger-config
kubectl get nodes

0.2: Understand the Application Before Deploying it

Open these files before running a single kubectl command. Reading the code first builds context that makes everything else make sense.

Notice this line in every Dockerfile: USER appuser. It means the image is designed to run as a normal user instead of root. The Kubernetes manifests also set runAsNonRoot: true. Later, in Stage 4, Kyverno enforces that rule and rejects pods that don't declare they run as non-root. Your app is prepared early so it passes that policy later.

Also look at infra/manifests/auth-service/secret.yaml. The database password is changeme-stage0 encoded in base64. Decode it:

echo "Y2hhbmdlbWUtc3RhZ2Uw" | base64 -d
# changeme-stage0

That password is sitting in a YAML file anyone with repo access can read. base64 is encoding, not encryption. It's trivially reversible. Remember this moment. It's why Stage 5 exists.

0.3: Docker Hub Setup

You need a container registry: a place to store the built images so the cluster can pull them. Docker Hub is the simplest option. You'll replace it with a private registry (ECR) in Stage 8.

Create four public repositories on Docker Hub (free account, hub.docker.com):

1. Go to hub.docker.com

2. Click Create repository

3. Choose your Docker Hub username as the namespace

4. Enter one repository name from the list below

5. Set visibility to Public

6. Click Create

7. Repeat for all four services

YOUR_USERNAME/clearledger-auth-service
YOUR_USERNAME/clearledger-ledger-service
YOUR_USERNAME/clearledger-notification-service
YOUR_USERNAME/clearledger-frontend

Next, generate an access token. Go to hub.docker.com, then Account Settings, Security, and New Access Token (Read/Write/Delete). Save it. You won't see it again.

docker login
# Username: your Docker Hub username
# Password: the access token (NOT your account password)

Build and push all four services:

# Replace your-username with your Docker Hub username, the same string everywhere in this lab
export DOCKER_USERNAME=your-username
echo "Using DOCKER_USERNAME=$DOCKER_USERNAME"

✋ Hands-on checkpoint: Docker Hub username

# Must print your real username, not the literal text "your-username"
echo "$DOCKER_USERNAME"

Expected: one line with your Docker Hub name (for example, veeno-demo). If you see your-username instead, stop and fix export before building.

Build and push all four services:

docker build -t $DOCKER_USERNAME/clearledger-auth-service:v0.1.0 ./app/auth-service
docker build -t $DOCKER_USERNAME/clearledger-ledger-service:v0.1.0 ./app/ledger-service
docker build -t $DOCKER_USERNAME/clearledger-notification-service:v0.1.0 ./app/notification-service
docker build -t $DOCKER_USERNAME/clearledger-frontend:v0.1.0 ./app/frontend

# Push

docker push $DOCKER_USERNAME/clearledger-auth-service:v0.1.0
docker push $DOCKER_USERNAME/clearledger-ledger-service:v0.1.0
docker push $DOCKER_USERNAME/clearledger-notification-service:v0.1.0
docker push $DOCKER_USERNAME/clearledger-frontend:v0.1.0

✋ Hands-on checkpoint: images on Docker Hub

Open hub.docker.com and go to your profile, then Repositories. Then confirm that all four clearledger-* repos exist and each shows tag v0.1.0.

On your laptop, run:

docker pull $DOCKER_USERNAME/clearledger-auth-service:v0.1.0

Expected: Status: Downloaded newer image or Image is up to date, not repository does not exist or denied.

0.4: Look at the Manifests Before Applying Them

Kubernetes uses manifest files (YAML) to describe the resources it should create. Instead of clicking buttons, you declare the desired state, and Kubernetes creates it.

Before deploying ClearLedger, take a quick look at these manifests:

• infra/manifests/namespace.yaml: Creates the clearledger namespace.

• infra/manifests/postgres/: Deploys PostgreSQL.

• infra/manifests/redis/redis.yaml: Deploys Redis.

• infra/manifests/auth-service/: Deploys the authentication service.

• infra/manifests/ledger-service/: Deploys the ledger service.

• infra/manifests/notification-service/: Deploys the notification service.

• infra/manifests/frontend/: Deploys the web application.

• infra/manifests/ingress.yaml: Makes the application available at clearledger.local.

• infra/manifests/rbac/rbac.yaml: Defines who may do what inside the cluster.

You don't need to understand every field yet. The goal is simply to see how the application is described before Kubernetes creates it.

You'll understand how Ingress routing and RBAC work in the two optional sections after §0.6. For now, just see how the app is described before Kubernetes creates it.

0.5: Deploy ClearLedger (Layer by Layer)

Deploy in six layers. Finish each layer before starting the next. Run kubectl get pods -n clearledger after layers 2, 3, and 6 to confirm progress.

Set a short path variable and confirm your username is still set:

export DOCKER_USERNAME=your-username   # skip if already set in §0.3
STAGE0=stages/stage-0-raw-kubernetes/infra/manifests

0.5.1 — Layer 1: Namespace and RBAC

Nothing else can be created until the namespace exists. RBAC also must exist before workloads reference ServiceAccounts.

kubectl apply -f infra/manifests/namespace.yaml
kubectl apply -f infra/manifests/rbac/rbac.yaml

Verify:

kubectl get namespace clearledger
kubectl get serviceaccount -n clearledger
# Expected: auth-service, ledger-service, notification-service, clearledger-viewer

0.5.2 — Layer 2: PostgreSQL

Database must be running before auth-service or ledger-service start. Both services connect to Postgres on startup to run migrations and serve requests, and they'll crash-loop if the database isn't there yet.

kubectl apply -f infra/manifests/postgres/postgres-secret.yaml
kubectl apply -f infra/manifests/postgres/postgres.yaml

kubectl wait --for=condition=ready pod -l app=postgres \
  -n clearledger --timeout=120s

Expected after kubectl apply:

secret/postgres-secret created
persistentvolumeclaim/postgres-pvc created
statefulset.apps/postgres created
service/postgres created

Expected when kubectl wait succeeds: the command exits with no output (exit code 0). If it times out, see If Postgres stays Pending below before continuing.

Verify:

kubectl get pods -n clearledger -l app=postgres
kubectl get pvc -n clearledger

Expected:

NAME         READY   STATUS    RESTARTS   AGE
postgres-0   1/1     Running   0          45s

NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
postgres-pvc   Bound    pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   5Gi        RWO            microk8s-hostpath   45s

If Postgres stays Pending (kubectl wait times out, pod shows 0/1 Pending, PVC shows Pending):

Postgres needs a PersistentVolumeClaim: disk space on the cluster. MicroK8s provides that through the hostpath-storage addon. If make setup was interrupted or you used manual setup without microk8s enable storage, the PVC has nothing to bind to and the pod never schedules.

Check the events: you'll usually see something like:

Warning  FailedScheduling  ...  pod has unbound immediate PersistentVolumeClaims
Normal   FailedBinding     ...  no persistent volumes available for this claim and no storage class is set

Fix it on the VM, then restart the postgres pod. Run this from your host: the same command on macOS, Linux, or Windows PowerShell (Multipass is installed on the host. It executes inside the VM for you):

# Enable storage (and ingress/rbac if make setup skipped them)
multipass exec clearledger -- microk8s enable storage ingress rbac

# Confirm a default StorageClass exists
kubectl get storageclass
# Expected: microk8s-hostpath (default)

# Kick the pod so it reschedules against the new storage class
kubectl delete pod postgres-0 -n clearledger

kubectl wait --for=condition=ready pod -l app=postgres \
  -n clearledger --timeout=120s
kubectl get pods -n clearledger -l app=postgres
# Expected: postgres-0   1/1   Running

Don't continue to auth-service or ledger-service until Postgres is Running. They will crash-loop without a database.

0.5.3 — Layer 3: Redis

Why Redis is here (a quick scenario): Imagine a customer posts a $15,000 debit. Ledger-service saves it to Postgres, then publishes a message to Redis: "large transaction, user X, amount 15000." Notification-service is listening on that channel. It picks up the message and records a compliance alert: the one you'll see in the UI later when you curl /notifications/alerts.

Ledger-service and notification-service don't call each other directly. Redis sits in the middle as a message bus: ledger publishes, notification subscribes. That's why Redis must be running before you deploy notification-service (and why you deploy it now, alongside Postgres, before the app layer).

kubectl apply -f infra/manifests/redis/redis.yaml

Verify:

kubectl get pods -n clearledger -l app=redis

Expected:

NAME                     READY   STATUS    RESTARTS   AGE
redis-xxxxxxxxxx-xxxxx   1/1     Running   0          30s

0.5.4 — Layer 4: Application secrets

Credentials live in Kubernetes Secrets for Stage 0 (Stage 5 moves them to Vault).

kubectl apply -f infra/manifests/auth-service/secret.yaml
kubectl apply -f infra/manifests/ledger-service/secret.yaml

Verify:

kubectl get secrets -n clearledger | grep -E 'auth-service|ledger-service'

Expected (AGE will differ, DATA counts must match):

auth-service-secret     Opaque   2      64s
ledger-service-secret   Opaque   1      8s

auth-service-secret holds two keys (database_url, jwt_secret). ledger-service-secret holds one (database_url). Stage 5 replaces these with Vault, for now they live in the cluster as Kubernetes Secrets.

0.5.5 — Layer 5: Application workloads

You're about to start the four app services: auth, ledger, notification, and frontend. Postgres, Redis, and the Secrets from the last two layers are already in place. Now Kubernetes needs to pull your Docker Hub images and run them as pods.

Two files per service (mostly): A Deployment tells Kubernetes which container image to run and how many copies. A Service gives that app a stable name inside the cluster (for example, auth-service so ledger can find auth without knowing pod IP addresses). You apply the Deployment first, then the Service.

So why are we using the sed command below? The deployment YAML files in Git contain a placeholder: literally the text DOCKER_USERNAME, because everyone's Docker Hub username is different. You already set yours in §0.3 (export DOCKER_USERNAME=YOUR_DOCKERHUB_USERNAME). The sed line swaps that placeholder for your real username on the fly, as the manifest is sent to Kubernetes. You never edit the file in Git. If you skip sed and apply the raw file, Kubernetes tries to pull an image called DOCKER_USERNAME/clearledger-auth-service, which doesn't exist.

Why do we use the Stage 0 folder? This repo has more than one copy of the Kubernetes manifests. For this manual deployment, use stages/stage-0-raw-kubernetes/infra/manifests/. Those files are prepared for Stage 0 and contain the DOCKER_USERNAME placeholder that the commands below replace. Don't use infra/manifests/ yet, as those files are for the GitOps stages later.

Deploy each service in order. Run these from the repo root with DOCKER_USERNAME still exported:

1. auth-service: login and registration

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" \
  "$STAGE0/auth-service/deployment.yaml" | kubectl apply -f -
kubectl apply -f infra/manifests/auth-service/service.yaml

2. ledger-service: transactions and balance (needs Postgres + the secret you created in §0.5.4)

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" \
  "$STAGE0/ledger-service/deployment.yaml" | kubectl apply -f -
kubectl apply -f infra/manifests/ledger-service/service.yaml

3. notification-service: listens on Redis for large-transaction alerts (no database secret in this one)

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" \
  "$STAGE0/notification-service/deployment.yaml" | kubectl apply -f -
kubectl apply -f infra/manifests/notification-service/service.yaml

4. frontend: the web UI (Deployment and Service are in one file here)

sed "s|DOCKER_USERNAME|${DOCKER_USERNAME}|g" \
  "$STAGE0/frontend/deployment.yaml" | kubectl apply -f -

Verify (all app pods should reach Running: auth and ledger may take ~30s while they connect to Postgres):

kubectl get pods -n clearledger

Expected. You should see Postgres and Redis from earlier layers plus new pods for each app (exact pod names vary):

NAME                                      READY   STATUS    RESTARTS   AGE
postgres-0                                1/1     Running   0          15m
redis-xxxxxxxxxx-xxxxx                    1/1     Running   0          10m
auth-service-xxxxxxxxxx-xxxxx             1/1     Running   0          45s
auth-service-xxxxxxxxxx-xxxxx             1/1     Running   0          45s
ledger-service-xxxxxxxxxx-xxxxx           1/1     Running   0          40s
ledger-service-xxxxxxxxxx-xxxxx           1/1     Running   0          40s
notification-service-xxxxxxxxxx-xxxxx     1/1     Running   0          35s
frontend-xxxxxxxxxx-xxxxx                 1/1     Running   0          30s

If auth-service or ledger-service is CrashLoopBackOff, check the logs:

kubectl logs -n clearledger deploy/auth-service --tail=20

Common cause: you applied infra/manifests/*/deployment.yaml instead of the Stage 0 files above: logs may show DATABASE_URL is not set. Re-run the sed + kubectl apply commands in this section.

✋ Hands-on checkpoint: workloads before ingress

kubectl get deployment -n clearledger
kubectl get pods -n clearledger --field-selector=status.phase!=Running

Expected: four Deployments (auth-service, ledger-service, notification-service, frontend) with READY matching desired replicas (auth and ledger show 2/2). The second command prints nothing: no pods stuck in Pending or CrashLoopBackOff.

0.5.6 — Layer 6: Ingress

Exposes the cluster to http://clearledger.local.

kubectl apply -f infra/manifests/ingress.yaml

Verify:

kubectl get ingress -n clearledger
curl -s -o /dev/null -w "%{http_code}\n" http://clearledger.local/
# Expected: 200

0.5.7: Watch until stable

kubectl get pods -n clearledger -w

Expected final state (press Ctrl+C to stop watching once all pods show Running):

NAME                                  READY   STATUS    RESTARTS
auth-service-xxx                      1/1     Running   0
auth-service-yyy                      1/1     Running   0
frontend-xxx                          1/1     Running   0
ledger-service-xxx                    1/1     Running   0
ledger-service-yyy                    1/1     Running   0
notification-service-xxx              1/1     Running   0
postgres-0                            1/1     Running   0
redis-xxx                             1/1     Running   0

Pod stuck in Pending or CrashLoopBackOff? These two commands show you what went wrong:

kubectl describe pod POD_NAME -n clearledger
kubectl logs POD_NAME -n clearledger --previous

0.6: Verify the Running System

Use one test account for both browser and curl so nothing conflicts:

If you already registered in the browser with a different password, either sign in with that password or pick a new email: the curl commands below must use the same email and password you actually registered with.

Browser verification (recommended):

Open http://clearledger.local in your browser. You should see the ClearLedger login screen.

Click Register and create an account with test@clearledger.io / SecurePass123 (same as the curl block below. Pydantic rejects obviously fake emails like test@test.com).

Sign in with that email and password. On first login the dashboard auto-seeds demo transactions. Wait a few seconds for them to appear:

Look at the Current Balance card. It should show a dollar amount with a sparkline chart.

Look at Transaction History. You should see entries like "Salary (Acme Corp", "Rent) May 2026", and so on.

And look at the Alerts panel at the bottom. You should see LARGE_TRANSACTION alerts with a red badge. Two of the demo transactions exceed $10,000, which triggers the compliance alert automatically.

Then submit your own transaction over $10,000 and watch the alert count increase in real time.

What to look for:

• Balance updates immediately after each transaction

• Credits show as green +$ amounts, debits show as red −$ amounts

• The Alerts badge count increases when you submit a transaction ≥ $10,000

• Each alert shows the amount, direction, and timestamp

Take a screenshot of the dashboard showing transactions and at least one alert. This is the first piece of your portfolio.

Alternatively via curl (same account: useful if the browser is not cooperating):

# Register (skip if you already registered in the browser with the same email)
curl -s -X POST http://clearledger.local/auth/register \
  -H "Content-Type: application/json" \
  -d '{"email":"test@clearledger.io","password":"SecurePass123"}' | jq .

Expected: {"user_id":"...","email":"test@clearledger.io"}, or an error that the email is already registered (fine if you used the browser first).

# Login — save the token (must match the password you registered with)
TOKEN=$(curl -s -X POST http://clearledger.local/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@clearledger.io","password":"SecurePass123"}' \
  | jq -r .access_token)
echo "Token: ${TOKEN:0:30}..."

If TOKEN is empty or login returns 401, your browser password doesn't match: re-register with the table above or use your actual password in the -d JSON.

# Create a large transaction (triggers notification alert)
curl -s -X POST http://clearledger.local/ledger/transactions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"amount":15000,"direction":"debit","description":"Property payment"}' | jq .

Expected: a transaction object with id, amount: 15000, direction: "debit":

# Check balance
curl -s http://clearledger.local/ledger/balance \
  -H "Authorization: Bearer $TOKEN" | jq .

# Confirm the notification alert fired
curl -s http://clearledger.local/notifications/alerts | jq .

Expected (curl-only path, no browser demo seed): at least one alert for the $15,000 transaction, for example, {"total":1,"alerts":[{"type":"LARGE_TRANSACTION","amount":15000,...}]}. If you already used the browser, total may be 3 or more (two demo alerts plus yours), that is also correct.

If you see {"detail":"Unauthorized"}: your token has expired. JWTs are short-lived for security. This is intentional. Re-run the login command above to get a fresh token, then retry the failed command.

This only affects the $TOKEN variable in your current terminal session. If you open a new terminal, you need to run the login command again because $TOKEN doesn't persist across sessions.

make check-0

Understanding Ingress (Optional)

Read this after §0.6 if you want to understand how clearledger.local reaches your pods.

Your cluster runs four application services: frontend, auth-service, ledger-service, and notification-service. Each has an internal Service address inside the cluster, but none are reachable from your browser until an Ingress routes external traffic.

The Ingress is the front door. When a request hits clearledger.local, Kubernetes looks at the URL path and forwards to the right service. Requests to /auth go to auth-service, /ledger to ledger-service, /notifications to notification-service, and / to the frontend.

Open infra/manifests/ingress.yaml and read the comments. The API paths use a rewrite: /auth/login becomes /login before it reaches auth-service, so backend routes stay simple.

You'll add more hostnames later (grafana.local, argocd.local, and so on): each gets its own Ingress manifest in a later stage. This file is only the ClearLedger app.

Understanding RBAC (Optional)

Ingress controls traffic coming from outside the cluster. RBAC controls permissions inside the cluster.

This file creates identities and permissions for the clearledger namespace.

Open infra/manifests/rbac/rbac.yaml. The comments at the top mirror this walkthrough.

A ServiceAccount is an identity for a pod. For example, auth-service, ledger-service, and notification-service each get their own identity.

A Role says what that identity is allowed to do. In your repo, the app roles are very limited: they can only get and list Kubernetes Endpoints. They can't read Secrets, delete pods, create resources, or access other namespaces.

A RoleBinding connects the identity to the permissions. Without the RoleBinding, the Role exists but no pod receives those permissions.

The clearledger-viewer ServiceAccount is for read-only debugging. It can inspect pods, services, endpoints, events, and configmaps, but it can't read Secrets.

The default ServiceAccount is bound to a role with zero permissions. That way, if a pod forgets to set serviceAccountName, it falls back to an identity that can do nothing.

The point is least privilege: even if a pod is compromised, Kubernetes doesn't hand it broad cluster access.

0.7: Why Manual Deploys Can't Be Trusted

In Stage 0, you built and deployed the app by hand. Now you'll make one small code change and deploy it again. This shows the problem with manual deployments: they're hard to track, hard to roll back, and hard to prove. Stages 1 and 2 fix that with CI and GitOps.

Step 1: Make a visible change.

Open app/auth-service/main.py and find the /health endpoint. Change the return value so you can tell the new version is running:

# Before
return {"status": "ok", "service": settings.service_name}

# After — add a version field
return {"status": "ok", "service": settings.service_name, "version": "0.2.0"}

Save the file. This simulates a developer shipping a small fix.

Step 2: Build, push, and deploy by hand.

docker build -t $DOCKER_USERNAME/clearledger-auth-service:v0.2.0 ./app/auth-service

docker push $DOCKER_USERNAME/clearledger-auth-service:v0.2.0
kubectl set image deployment/auth-service \
  auth-service=$DOCKER_USERNAME/clearledger-auth-service:v0.2.0 \
  -n clearledger

Wait about 30 seconds for Kubernetes to pull the new image and restart the pods:

kubectl rollout status deployment/auth-service -n clearledger

Step 3: Verify your change is live.

curl -s http://clearledger.local/auth/health | jq .

Expected: {"status":"ok","service":"auth-service","version":"0.2.0"}

If you still see the old response without "version", wait a few more seconds and retry. Kubernetes is still rolling out the new pods.

Step 4: Notice what manual deploy doesn't give you.

You deployed a change. It works. But think about what just happened:

• Who deployed this? There's no record. You ran kubectl from your laptop. If three people have cluster access, no one knows who changed what.

• What changed? The only evidence is the Docker Hub tag v0.2.0. Nothing links that tag to a specific commit or code review.

• What if v0.2.0 is broken? You would need to remember the previous tag, then run kubectl set image again to roll back. What if you don't remember the tag? What if the previous image was deleted?

• What if someone else runs kubectl apply with v0.1.0 while you're pushing v0.2.0? The cluster silently reverts to the old version. No error. No notification. You think your fix is live, but it's not.

• Where is the audit trail? Nowhere. In a regulated environment (banking, healthcare, government), you need proof of who deployed what and when. Right now you have nothing.

Manual deploys can work for a demo. But they don't hold up for a team or a regulated environment. Keep these gaps in mind. They're why the next stages exist.

Step 5: Revert your change before continuing.

Undo the health endpoint change in app/auth-service/main.py (remove "version": "0.2.0"). Don't rebuild: the cluster will keep running v0.2.0 for now, and Stage 1 will take over image management.

Stage 1 automates the build. Stage 2 fixes the deployment.

What You Learned in Stage 0

• How to provision a local Kubernetes cluster with Multipass and MicroK8s

• How Kubernetes manifests describe the desired state of your system

• How an Ingress routes external traffic to internal services

• How to build, push, and deploy container images manually

• Why manual deploys can't be trusted: no audit trail, no rollback, no consistency

What you can now put on your CV / say in an interview:

Deployed a multi-service application to Kubernetes by hand: namespace, RBAC, a StatefulSet database, Deployments, Services, and path-based Ingress routing, and can explain why each layer deploys in that order.

make snapshot STAGE=0 && make snapshots. Confirm clearledger.stage0. See How to Save Your Progress.

Stage 1 — CI Pipeline (GitHub Actions + Self-Hosted Runner)

In Stage 0 you built and deployed by hand. Stage 1 automates the build: a git push runs a pipeline that builds images, scans them, pushes to Docker Hub, and records the new tag in clearledger-infra.

Goal: every push to GitHub automatically builds images, pushes them to Docker Hub, and updates image tags in clearledger-infra.

Am I ready for Stage 1?

Run these yourself before §1.1:

make check-0
echo "$DOCKER_USERNAME"    # must not be empty or "your-username"
curl -s -o /dev/null -w "%{http_code}" http://clearledger.local/auth/health

Expected: health check green, echo prints your Docker Hub user, and curl prints 200.

What you'll need for this section:

• Docker Hub account with four clearledger- repositories (see QUICKSTART.md §1b)

• GitHub account: you can create repos and personal access tokens

• ~2–4 hours for runner install + first green pipeline (this is the hardest stage for beginners)

• Done when: make check-1 passes and you manually confirmed the five items in §1.7 below. Then save: make snapshot STAGE=1 → make snapshots (confirm clearledger.stage1).

What You Need to Know First

In Stage 0, your laptop was the deployment system.

You typed docker build, docker push, and kubectl set image yourself. That worked for a demo, but it's not how teams should ship software.

Manual builds create too many unanswered questions:

• Did this image come from the latest code?

• Did someone build it from a dirty working tree?

• Did the build work the same way on another machine?

• Which commit produced the image currently running?

• Who pushed the image, and when?

CI (Continuous Integration) fixes the build side of that problem. It means that every time code is pushed, an automated system builds, checks, and packages it the same way.

Think of CI as a factory line:

Developer pushes code
        ↓
GitHub detects the push
        ↓
GitHub Actions starts the pipeline
        ↓
Runner executes the jobs
        ↓
Docker images are built and pushed
        ↓
Infra manifests are updated with the new image tags  (in clearledger-infra — §1.3)

The important idea is that the build no longer depends on your laptop. Your laptop writes code and the pipeline produces the release artifact.

A CI system has three parts:

1. Pipeline host: the control plane. It notices a push and decides which workflow to run. In this lab, that's GitHub Actions.

2. Pipeline file: the instructions. It's a YAML file at .github/workflows/ci.yaml that says what jobs to run.

3. Runner: the worker machine. It actually executes the commands in the pipeline.

GitHub Actions normally uses GitHub-hosted runners in the cloud. In this lab, that's not enough. Your Kubernetes cluster lives inside a local Multipass VM and GitHub's cloud runner can't reach it. You also need the runner inside the VM to build Docker images using the local Docker daemon.

So you install a self-hosted runner inside the VM. It connects outbound to GitHub, waits for work, then executes pipeline jobs locally where it can reach everything.

Two repos, clearledger (code + CI) and clearledger-infra (Kubernetes YAML only). You'll create the second in §1.3.

GitHub — clearledger (app repo)
  stores your code
  starts the workflow on git push
        ↓
Self-hosted runner (inside Multipass VM)
  builds Docker images
  pushes images to Docker Hub
  updates image tags in clearledger-infra  ← you create this in §1.3
        ↓
GitHub — clearledger-infra (infra repo)
  stores Kubernetes YAML with the new image tags
  ArgoCD watches this repo in Stage 2 (not yet)

For Stages 1–7, the lab uses .github/workflows/ci.yaml with your self-hosted runner. It builds images, pushes them to Docker Hub, and updates clearledger-infra. Stage 8 adds a separate AWS workflow, .github/workflows/ci-aws.yaml, which pushes to ECR instead. You don't need to configure the AWS workflow until you reach Stage 8.

1.1: Push the App Repo to GitHub (Not clearledger-infra Yet)

This step is repo #1, clearledger (application code + CI workflow). You're pushing the clone on your laptop: the same folder where you ran Stage 0 (make setup, kubectl apply, and so on).

clearledger-infra comes later in §1.3. That second repo holds Kubernetes manifests only. Don't create it here.

First, put the application repo somewhere GitHub Actions can see it.

Go to GitHub and then New Repository:

• Repository name: clearledger (exact name, not clearledger-infra)

• Visibility: Public or Private. Both work with the self-hosted runner and GitHub Actions. ArgoCD never reads this repo (see Private repos: what syncs where in §1.3).

• Do not initialize with a README or .gitignore

The repo already has those files locally. If GitHub creates its own, your first push may fail because the histories don't match.

Run from your local clearledger project root on your laptop (where app/, infra/, and .github/workflows/ci.yaml live):

cd ~/Desktop/clearledger   # your clone path
git remote add origin https://github.com/YOUR_USERNAME/clearledger.git
git branch -M main
git push -u origin main

If git remote add fails because origin already exists:

git remote -v
git remote set-url origin https://github.com/YOUR_USERNAME/clearledger.git
git push -u origin main

Verify in the browser: https://github.com/YOUR_USERNAME/clearledger.

You should see app/, infra/manifests/, docs/, and .github/workflows/ci.yaml. That confirms GitHub can trigger the pipeline on your next push.

What you proved: the app repo is on GitHub. CI will run from here. Deployment manifests for GitOps land in clearledger-infra in §1.3.

1.2: Install the Self-Hosted Runner Inside the VM

The workflow file tells GitHub what to run. The runner is where it runs.

This lab uses a self-hosted runner because your infrastructure is local. GitHub's cloud servers can't reach your MicroK8s cluster or Docker daemon inside the Multipass VM. The runner solves that by living inside the VM. It connects to GitHub to pick up jobs, then executes everything locally.

If the runner is missing or offline, the pipeline can't execute. The workflow may sit queued, or it may fail because no matching runner is available.

Step 1: Open GitHub’s runner setup page (keep this tab open)

GitHub gives you a full copy-paste install guide on one page. Use it: don’t hunt for URLs or tokens elsewhere.

1. Open https://github.com/YOUR_USERNAME/clearledger

2. Go to Settings, Actions, Runners, and New self-hosted runner

3. Select Linux and x64

The page title should look like: Add new self-hosted runner · YOUR_USERNAME/clearledger.

That page has three sections you'll use:

Scroll to Configure. You'll see something like:

./config.sh --url https://github.com/YOUR_USERNAME/clearledger --token AXXXXXXXXXXXXXXXXXXXXXXXXX
./run.sh

The token is the long string after --token (starts with A, about 26 characters). Copy only that string.

Keep this tab open until Step 4 finishes: the token expires in about 1 hour. If it expires, click New self-hosted runner again for a fresh token.

Step 2: Enter the VM

multipass shell clearledger

After this command, your prompt should look like ubuntu@clearledger:~$. That means you are inside the Ubuntu VM. If your prompt still shows your Mac username or MacBook name, you're still on your host machine and the runner setup will fail.

Continue only when your prompt shows ubuntu@clearledger.

Everything from Step 3 onwards runs inside the VM, not on your Mac.

Step 3: Install Docker inside the VM

The runner will build Docker images. That means Docker must exist where the runner runs.

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker ubuntu
newgrp docker

docker --version

Expected: Docker prints a version number (for example, Docker version 29.x.x).

Verify Docker works for the ubuntu user now: the runner doesn't exist yet (Step 4 creates ~/actions-runner):

docker ps

Expected: a table header (CONTAINER ID, IMAGE, …), even if no containers are listed. Not permission denied while trying to connect to the Docker API.

If docker ps fails with permission denied, the docker group has not applied yet. Run newgrp docker again, or log out of the VM (exit) and multipass shell clearledger back in, then retry docker ps.

What you proved: the VM can run Docker without Docker Desktop on your Mac. Continue to Step 4 to install the runner.

Step 4: Install and register the runner

Still inside the VM (ubuntu@clearledger prompt):

Download: you can copy the commands from the Download section on GitHub’s runner page (Step 1), or run the block below. They should match. Paste into the VM, not your Mac.

Configure: use the lab command below, not GitHub’s ./config.sh line. Paste your token from Step 1 and replace YOUR_USERNAME.

mkdir -p ~/actions-runner && cd ~/actions-runner

curl -o actions-runner-linux-x64-2.335.1.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.335.1/actions-runner-linux-x64-2.335.1.tar.gz

tar xzf ./actions-runner-linux-x64-2.335.1.tar.gz

./config.sh \
  --url https://github.com/YOUR_USERNAME/clearledger \
  --token YOUR_RUNNER_TOKEN \
  --name clearledger-runner \
  --labels clearledger,self-hosted,linux \
  --work _work \
  --unattended

sudo ./svc.sh install
sudo ./svc.sh start

Do not run GitHub’s ./run.sh for day-to-day use: the lab uses sudo ./svc.sh so the runner survives VM reboots. GitHub shows ./run.sh for a quick test only.

Expected after ./config.sh: Runner successfully added (or similar). If you see Invalid token or Expired token, go back to Step 1 in the browser and copy a fresh token.

The clearledger label is required GitHub’s default ./config.sh on the setup page doesn't add it. The workflow uses:

runs-on: [self-hosted, clearledger]

GitHub schedules jobs by runner labels, not by runner name. A runner named clearledger without the clearledger label will stay online but jobs will remain queued with Waiting for a runner to pick up this job.

What those last two commands mean:

sudo ./svc.sh install
  Registers the runner with systemd inside the VM.
  Without this, `sudo ./svc.sh status` says: not installed.

sudo ./svc.sh start
  Starts the runner service in the background.
  After this, it keeps running even when you close the terminal.

Check it locally from the same folder, still inside the VM:

cd ~/actions-runner
sudo ./svc.sh status

Expected: the service is installed and running.

If docker ps worked in Step 3 but a CI job later fails with Docker socket permission denied, the runner probably started before the docker group applied. Restart it after Step 4 (only when ~/actions-runner exists):

cd ~/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh start
docker ps    # must work without sudo

Or, if you started the runner manually with ./run.sh instead of systemd:

cd ~/actions-runner
pkill -f "Runner.Listener|Runner.Worker|./run.sh" || true
nohup ./run.sh > _diag/manual-runner.log 2>&1 &
docker ps

If you see this:

not installed

then sudo ./svc.sh install didn't run successfully. Run:

cd ~/actions-runner
sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status

If install fails, rerun ./config.sh with a fresh GitHub runner token, then run the install/start commands again.

Step 5: Exit the VM

exit

Step 6: Verify the runner is connected

Go to github.com/YOUR_USERNAME/clearledger then to Settings, Actions, and Runners.

You should see clearledger-runner with a green dot and status Idle. Open the runner details and confirm the labels include:

self-hosted
Linux
X64
clearledger

If clearledger is missing, add it in the runner settings before rerunning the workflow. The runner name alone is not enough.

✋ Hands-on checkpoint: runner ready for jobs

Still on GitHub, Settings, Actions, and Runners, confirm:

Then trigger a dry run from your laptop:

git commit --allow-empty -m "test: verify runner picks up jobs"
git push

Open https://github.com/YOUR_USERNAME/clearledger/actions. Within 30 seconds a workflow run should show Queued then In progress, not stuck on “Waiting for a runner.” If it waits more than 2 minutes, the labels are wrong. Edit the runner on GitHub and add clearledger.

If it shows Offline:

multipass exec clearledger -- sudo systemctl status actions.runner.*.service
multipass exec clearledger -- journalctl -u actions.runner.*.service --lines=50

What you proved: GitHub can now send work into your local lab environment.

1.3: Create the Infra Repo on GitHub

Now separate application code from deployment state. Stage 1 introduces a second GitHub repository alongside the clearledger app repo you pushed in §1.1.

You'll use two repositories for the rest of the lab:

Think of clearledger as the question “What is the application?”. Python services, Dockerfiles, tests, and the CI workflow. Think of clearledger-infra as “What exact version should be running in Kubernetes right now?”. Deployments, Services, ingress rules, and the image tags that point at Docker Hub.

Teams split these on purpose. If you edit README.md in clearledger, that is a documentation change. It shouldn't trigger a deployment.
If you change auth-service code, the pipeline builds a new image (for example tag abc123) and, only after scans pass, records that tag in clearledger-infra:

image: $DOCKER_USERNAME/clearledger-auth-service:abc123

That line is a deployment contract: Git now says the cluster should run abc123. In Stage 1, the cluster doesn't change yet (and you'll prove that in §1.6).
In Stage 2, ArgoCD watches clearledger-infra, compares Git to what is running, and syncs the cluster when they differ. The app repo is where work begins. The infra repo is what production is supposed to look like.

Private repos: what syncs where

This lab uses two GitHub repos. clearledger is your main project repo: app code, CI pipeline, docs, policies, and lab files. This repo can be private.

clearledger-infra contains only Kubernetes manifests. ArgoCD watches this repo and uses it to deploy the app. For beginners, make this repo public so ArgoCD can read it without extra authentication.

The flow looks like this:

clearledger
app code + infra/manifests/
        ↓
CI copies infra/manifests/
        ↓
clearledger-infra
Kubernetes manifests only
        ↓
ArgoCD syncs from this repo
        ↓
Kubernetes cluster

ArgoCD doesn't read the main clearledger repo. It only reads clearledger-infra. If clearledger is private, that is fine. If clearledger-infra is private, you must give ArgoCD GitHub credentials later. If you do not, ArgoCD may show ComparisonError.

Create the infra repo on GitHub:

1. Go to GitHub and then New Repository

2. Name it clearledger-infra

3. Choose Public

4. Don't add a README

5. Click Create

Later, the CI pipeline will update clearledger-infra automatically. In Stage 1, the pipeline doesn't run kubectl apply – it updates Git. In Stage 2, ArgoCD reads that Git repo and applies it to the cluster.

Before pushing: set your Docker Hub username in Kustomize (image tags are resolved here, not in deployment YAML):

# Replace YOUR_DOCKERHUB_USERNAME with the same value as $DOCKER_USERNAME from §0.3
sed -i.bak "s/YOUR_DOCKERHUB_USERNAME/${DOCKER_USERNAME}/g" infra/manifests/kustomization.yaml
rm -f infra/manifests/kustomization.yaml.bak

Push only the Kubernetes manifests from infra/manifests/ (not everything under infra/):

mkdir -p /tmp/clearledger-infra
cp -r infra/manifests /tmp/clearledger-infra/
cd /tmp/clearledger-infra
git init
git remote add origin https://github.com/YOUR_USERNAME/clearledger-infra.git
git add . && git commit -m "feat: initial manifests" && git push -u origin main
cd -

✋ Hands-on checkpoint: infra repo on GitHub (do this before §1.4)

On your laptop:

grep "docker.io/${DOCKER_USERNAME}/" infra/manifests/kustomization.yaml | wc -l
grep YOUR_DOCKERHUB_USERNAME infra/manifests/kustomization.yaml || echo "OK: placeholder replaced"

Expected: first command prints 4 (four image lines). Second prints OK: placeholder replaced, not four lines still saying YOUR_DOCKERHUB_USERNAME.

In the browser, open https://github.com/YOUR_USERNAME/clearledger-infra/tree/main/manifests and confirm with your eyes:

Which folders matter? You only pushed infra/manifests/ to GitHub, that's correct. Everything else in this repo stays local for now.

Some manifests for later stages (network policies, Vault extras) live under infra/deferred-by-stage/ in the clearledger repo. You'll apply those by hand when you reach that stage. Do not copy that folder into clearledger-infra, or ArgoCD will deploy things too early.

You might notice stages/stage-1-ci-pipeline/ has no copy of the manifests. That is normal: the lab doesn't duplicate YAML there. The canonical copy is infra/manifests/ in this repo, and the live GitOps copy is clearledger-infra on GitHub.

What you proved: Kubernetes config now has its own repo and Git history, separate from application code. CI will update clearledger-infra after each build, and your app repo stays for code and the pipeline file.

1.4: Set up GitHub Secrets

Go to github.com/YOUR_USERNAME/clearledger and then Settings, Secrets and variables, Actions, and New repository secret.

The workflow needs credentials for Docker Hub, GitHub, and image signing:

• Docker Hub, so it can push images.

• GitHub, so it can push image tag updates into clearledger-infra.

• Cosign, so it can sign the images after pushing them.

Do not paste these values into YAML files. Store them as GitHub Actions secrets.

Secret 1, DOCKER_USERNAME

This is just your Docker Hub username.

Example:

veeno-demo

Get it from Docker Hub: hub.docker.com, profile menu, Account Settings.

Secret 2, DOCKER_PASSWORD

This should be a Docker Hub access token, not your normal Docker Hub password.

Create it here:

hub.docker.com
→ Account Settings
→ Security
→ New Access Token
→ Description: clearledger-github-actions
→ Access permissions: Read, Write, Delete or Read/Write
→ Generate

Copy the token immediately. Docker Hub only shows it once.

Secret 3, INFRA_REPO_TOKEN

This is a GitHub Personal Access Token (PAT). The pipeline uses it to push commits to the second repo, clearledger-infra.

Create it here:

GitHub profile settings
→ Settings
→ Developer settings
→ Personal access tokens
→ Tokens (classic)
→ Click "Generate new token"
→ Choose "Generate new token (classic)"
→ If GitHub asks for your password or 2FA, complete it
→ Note: clearledger-infra-ci
→ Expiration: choose a lab-friendly value
→ Select scope: repo
   This allows the pipeline to push to clearledger-infra.
→ Generate token

Copy the token immediately. GitHub only shows it once.

For this lab, repo scope is the simplest option. In production, you would use tighter permissions, such as a fine-grained token limited to only clearledger-infra.

Secrets 4 and 5, COSIGN_PRIVATE_KEY and COSIGN_PASSWORD

Cosign signs container images after the pipeline pushes them to Docker Hub. Later, Stage 4 uses the public key with Kyverno so the cluster can verify that images came from your trusted pipeline.

Generate the key pair on your host machine, not inside the Multipass VM:

# macOS: brew install cosign
# Linux/WSL2: curl -sSL -o cosign https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 && chmod +x cosign && sudo mv cosign /usr/local/bin/
cosign generate-key-pair

This creates:

cosign.key   # private key — never commit this
cosign.pub   # public key — keep for later Kyverno verification

When Cosign asks for a password, enter one and save it in your password manager. If you already generated a key without a password, regenerate it with a password for this lab.

Add these five secrets to the clearledger repo, not clearledger-infra:

Repository variables (not secrets) (optional) toggles for later stages. Add under Settings, Secrets and variables, Actions, Variables:

Don't add either variable in Stage 1. If you set them now, CI will try to refresh ArgoCD or run ZAP before the cluster is ready, and the pipeline output gets harder to read. The guide calls out the exact moment to turn each one on – you only need to remember that both exist.

What you proved: the pipeline can authenticate to external systems without hardcoding credentials in the repo.

1.5: Understand the Pipeline Before Activating it

Don't treat the workflow file as magic. Open .github/workflows/ci.yaml and read it before you run it.

The pipeline has two responsibilities:

1. Prove the code and images are safe enough to publish.

2. Update the infra repo with the new image tags.

Here's the security flow first:

Developer pushes code to GitHub
        ↓
GitHub Actions starts workflow
        ↓
Self-hosted runner inside the Multipass VM picks up the job
        ↓
1. Scan secrets (Gitleaks)
        ↓
2. Run code security scans (Semgrep) + IaC scan (Checkov) — parallel
        ↓
3. Prepare scanners (install Trivy/Syft/Grype/Cosign once; refresh Trivy DB once)
        ↓
4. BUILD: docker build all four services (local tags only; nothing hits Docker Hub yet)
        ↓
5. SCAN: Trivy on all images; Syft + Grype SBOM on auth-service; upload evidence
        ↓
6. PUBLISH: push to Docker Hub + Cosign sign (only if scan passed)
        ↓
7. UPDATE MANIFESTS: commit new image tags to clearledger-infra

Build, scan, publish (prod-style gates)

Real teams never push first and scan later. The pipeline separates three concerns into three jobs in .github/workflows/ci.yaml:

You do not run scripts/ci-publish-image.sh yourself before pushing code. GitHub Actions checks out the repo and calls it inside publish-images.

Why can build-images and scan-images be separate jobs? Each job is a fresh checkout on GitHub-hosted runners. They don't share a disk. On your self-hosted runner, all three jobs run on the same Multipass VM and use the same Docker engine.

Job 1 runs docker build and leaves the images on that machine. Job 2 runs Trivy against those same local images: no upload, no download. Job 3 pushes to Docker Hub only if the scan passed.

That's a practical lab setup: one persistent build machine with Docker installed, like a dedicated CI worker in a real office. In Stage 8 (AWS), the pipeline uses GitHub-hosted runners instead: there, build-images saves the images to a file (images.tar) and passes that file to the next job as a workflow artifact, because those runners are throwaway VMs with no shared Docker cache.

Then comes the GitOps handoff:

Secure images now exist in Docker Hub
        ↓
Runner checks out clearledger-infra from GitHub
        ↓
Deployment YAML image tags are updated
        ↓
Runner commits and pushes back to clearledger-infra
        ↓
Stage 1 ends here

Here's how the image tag ties to your code: every pipeline run is triggered by a git commit. GitHub gives that commit a unique ID called the SHA (a long hex string like a1b2c3d4e5f6789…). The workflow sets IMAGE_TAG to that SHA and uses it everywhere:

1. Build: docker build -t clearledger-auth-service:a1b2c3d4…

2. Publish: push to Docker Hub as YOUR_DOCKERHUB_USERNAME/clearledger-auth-service:a1b2c3d4…

3. Update manifests: kustomize edit set image …:a1b2c3d4… in clearledger-infra

4. Commit message: ci: deploy a1b2c3d4… — all gates passed

If production is running YOUR_DOCKERHUB_USERNAME/clearledger-auth-service:a1b2c3d4, you can copy that a1b2c3d4 tag, open GitHub, and instantly find the exact commit that built that image. There's no guessing and no wondering if latest changed. Every deployed image points back to one specific version of the code, making rollbacks and debugging much easier.

The Kustomize placeholder

auth-service/deployment.yaml uses a label instead of a real image address:

image: clearledger/auth-service:gitops

That label isn't on Docker Hub. It tells Kustomize where to substitute. The real address lives in kustomization.yaml:

images:
  - name: clearledger/auth-service          # matches the label above
    newName: docker.io/YOUR_DOCKERHUB_USERNAME/clearledger-auth-service
    newTag: abc123def456…                   # real commit SHA — CI writes this

When ArgoCD deploys, kustomize build swaps the label for the full address.

You edit kustomization.yaml once in §1.3 to set your Docker Hub username in newName:. After that, CI writes newTag: automatically on every green push. You never touch it by hand.

Stage 1: CI updates GitHub, not the cluster

After a green pipeline run, three things are true:

• New images exist on Docker Hub

• clearledger-infra on GitHub has new SHAs in kustomization.yaml

• Your Kubernetes cluster is unchanged. Still running whatever Stage 0 left there

CI never runs kubectl apply. It only commits to clearledger-infra. That's the whole Stage 1 lesson: build and scan are automated, but deploy is not: yet. Stage 2 installs ArgoCD, which reads clearledger-infra and updates the cluster for you.

Kubernetes Checkov runs in Stage 1 but does not block the pipeline. It uploads findings so you can see hardening work ahead. Stage 4 turns those kinds of rules into cluster enforcement with Kyverno.

Jobs run on your self-hosted runner (runs-on: [self-hosted, clearledger]). Both ENABLE_ARGOCD_SYNC and ENABLE_DAST are unset in Stage 1. See §1.4 for when each gets flipped.

If a job fails, start with docs/troubleshooting.md before editing the workflow.

Stage 1 security posture: what blocks vs what waits

Note that stage 1 is not “security off.” Some gates stop the pipeline while others run for evidence and tighten in later stages.

Blocks the pipeline today:

• Gitleaks (secrets in Git)

• Semgrep (SAST on Python)

• Checkov on Dockerfiles

• Trivy (fixable HIGH/CRITICAL CVEs in images)

• Grype on auth-service SBOM (fixable HIGH+)

• Manifest update to clearledger-infra (must succeed)

Runs but doesn't block yet:

• Checkov on Kubernetes manifests – enforced in Stage 4 (Kyverno)

• Cosign sign + SLSA attest – enforced in Stage 4 (unsigned images rejected)

• Syft SBOM generation – supply-chain evidence. You'll purposely break gates in Stage 3.

• ArgoCD refresh – Stage 2 (ENABLE_ARGOCD_SYNC=true)

• DAST / ZAP – Stage 3 (ENABLE_DAST=true)

If you forget which stage fixes what, search this guide for “Stage 1 security posture” or follow the stage order: Stage 3 breaks gates on purpose, Stage 4 connects Checkov findings to Kyverno, Stage 5 moves secrets off Git, Stage 6 adds runtime detection, Stage 7 adds monitoring dashboards.

Run make check-3 and make check-4 after those stages to confirm hardening landed.

Design intent: Stage 1 proves CI can build, scan, push, and update Git without you touching Docker manually. Later stages turn evidence into enforcement. The relaxations here are deliberate.

1.6: Activate the Pipeline

Run this in the clearledger app repo, not clearledger-infra.

§1.3 created clearledger-infra with only Kubernetes manifests. It has no .github/workflows/ and no pipeline. If your shell prompt says clearledger-infra, or you used /tmp/clearledger-infra, you're in the wrong place.

cd /path/to/clearledger    # the app repo you pushed in §1.1

git remote -v              # must show .../clearledger.git — NOT clearledger-infra

ls .github/workflows/ci.yaml   # must exist before you commit

The pipeline file already lives at .github/workflows/ci.yaml. Push any small change to clearledger on main:

echo "# Pipeline activated $(date)" >> README.md
git add README.md
git commit -m "ci: activate GitHub Actions pipeline"
git push origin main

Watch the run at: https://github.com/YOUR_USERNAME/clearledger/actions (app repo Actions tab, not the infra repo).

When the pipeline succeeds, it updates clearledger-infra for you. You don't need to push anything to the infra repo by hand for this step.

Expected Output: all jobs green in about 8 minutes.

✓ Build + Scan auth-service
✓ Build + Scan ledger-service
✓ Build + Scan notification-service
✓ Build + Scan frontend
✓ Update manifests → GitHub

DAST and the ArgoCD refresh step show as skipped: this is expected, because Both toggles are unset until later (see §1.4).

Note: this lab includes .gitleaksignore because some intentional demo secrets are already present in Git history. Gitleaks still runs normally. The ignore file only suppresses known lab fingerprints. Don't add new findings to it unless you've confirmed they're intentional test data.

Click into the job logs and look for the story. Don't just wait for green:

• Docker login succeeded

• Each service image built and pushed to Docker Hub

• clearledger-infra was checked out

• Deployment YAMLs were updated with the new SHA tag

• A commit was pushed back to clearledger-infra

After the pipeline succeeds, open https://github.com/YOUR_USERNAME/clearledger-infra and look at the deployment manifests. The image tags should now use the current commit SHA.

Now check the cluster:

kubectl get deployment auth-service -n clearledger \
  -o jsonpath='{.spec.template.spec.containers[0].image}' && echo

You may still see the old image. That's expected. This is the most important learning in Stage 1:

GitHub pipeline succeeded.
Docker Hub has new images.
clearledger-infra has new image tags.
The Kubernetes cluster did not update automatically.

That's not a failure. It's the deployment gap. Stage 1 automated the build, but no controller is watching the infra repo yet. Stage 2 installs ArgoCD to close that gap.

1.7 — Hands-on Checkpoint: Prove Stage 1 is Really Done

Don't rely on a green workflow badge alone. Run each check yourself:

1. Infra repo still has app secrets (critical for Stage 2)

Open https://github.com/YOUR_USERNAME/clearledger-infra/tree/main/manifests/auth-service, secret.yaml must be visible.

On your laptop:

git clone --depth 1 https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/verify-infra
grep secretKeyRef /tmp/verify-infra/manifests/auth-service/deployment.yaml
grep secret.yaml /tmp/verify-infra/manifests/kustomization.yaml
rm -rf /tmp/verify-infra

Expected: secretKeyRef in deployment output. kustomization lists auth-service/secret.yaml and ledger-service/secret.yaml. If secrets are missing, re-push §1.3 manifests before Stage 2.

2. Kustomize image tags updated by CI

git clone --depth 1 https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/verify-infra
grep newTag /tmp/verify-infra/manifests/kustomization.yaml
rm -rf /tmp/verify-infra

Expected: newTag is a 40-character git SHA (or your commit hash), not still v0.1.0 only: unless you haven't pushed since §0.3.

3. Docker Hub has signed images from this pipeline

Open hub.docker.com then clearledger-auth-service then Tags. The latest tag should match the SHA from step 2.

4. (Cluster unchanged (deployment gap) intentional)

kubectl get deployment auth-service -n clearledger \
  -o jsonpath='{.spec.template.spec.containers[0].image}' && echo

Expected: still your Stage 0 tag (for example, veeno-demo/clearledger-auth-service:v0.1.0), not the new SHA. That proves CI didn't touch the cluster.

5. Runner still idle

GitHub, Settings, Actions, Runners, clearledger-runner, Idle.

make check-1

All five pass, onto Stage 2.

What You Learned in Stage 1

• CI removes your laptop from the build process. Builds become repeatable, visible, and tied to Git commits.

• A runner is the worker, not the pipeline itself. GitHub schedules the job, the self-hosted runner executes it inside your VM.

• Artifacts and desired state are different things. Docker Hub stores built images. clearledger-infra on GitHub stores the Kubernetes manifests that say which image should run.

• Good pipelines don't secretly mutate clusters. This pipeline updates Git instead of running kubectl.

• The gap that remains: the infra repo changed, but the cluster didn't. Someone still has to apply the change manually. Stage 2 fixes that with GitOps.

What you can now put on your CV / say in an interview:

Built a CI pipeline on a self-hosted GitHub Actions runner that builds and pushes container images on every push, and can debug a workflow that fails before any job is created.

make snapshot STAGE=1 && make snapshots. Confirm clearledger.stage1. See How to Save Your Progress.

Stage 2 — GitOps with ArgoCD

From this point on, Git is in charge. Whatever is written in the infrastructure repository is what should be running. If someone changes the cluster by hand, ArgoCD notices the difference and changes it back to match Git.

Goal: Install ArgoCD so it watches clearledger-infra and deploys changes to the cluster. The CI pipeline only updates the Git repository, it never connects to Kubernetes or runs kubectl commands.

Here's a more conversational, compressed version:

Am I ready for Stage 2?

Before moving on, finish §1.6, then run:

make check-1

grep secretKeyRef infra/manifests/auth-service/deployment.yaml

grep vault.hashicorp infra/manifests/auth-service/deployment.yaml && echo "STOP: Vault annotations present" || echo "OK"

You should see:

• check-1 passes

• secretKeyRef is present

• OK (no Vault annotations yet)

Quick checklist:

• clearledger-infra contains auth-service/secret.yaml and ledger-service/secret.yaml

• Your self-hosted runner is Idle with the clearledger label

• ENABLE_ARGOCD_SYNC isn't set yet (you'll enable it after installing ArgoCD)

You're done with Stage 2 when make check-2 passes and http://argocd.local shows ArgoCD syncing clearledger.

Finally, save your progress:

make snapshot STAGE=2
make snapshots

Confirm that clearledger.stage2 appears in the snapshot list.

What You Need to Know First

The gap from Stage 1: CI already builds images and updates clearledger-infra. The cluster didn't change until someone ran kubectl. This stage closes that last step.

push code → CI updates clearledger-infra → ArgoCD syncs cluster

Pre-sync Checklist: Run Before argocd app sync

ArgoCD applies whatever is in clearledger-infra. Wrong content causes red pods. Re-run the §1.7 checkpoint table to confirm GitHub-side content is still correct, then verify the laptop side:

# Application manifest must point at YOUR infra repo
grep repoURL stages/stage-2-gitops/argocd/clearledger-app.yaml

# Stage 0 workloads still healthy before ArgoCD takes over
kubectl get pods -n clearledger
curl -s -o /dev/null -w "%{http_code}" http://clearledger.local/auth/health

Expected: repoURL contains your GitHub username, all app pods Running, curl 200. Only when both pass should you install ArgoCD and sync below.

kubectl create namespace argocd 2>/dev/null || true

kubectl apply -n argocd --server-side --force-conflicts -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

kubectl wait --for=condition=ready pod \
  -l app.kubernetes.io/name=argocd-server -n argocd --timeout=180s

Why --server-side --force-conflicts? Argo CD ships a very large applicationsets.argoproj.io CRD. A normal kubectl apply tries to stash the whole thing in an annotation, hits a 256 KiB limit, and errors with metadata.annotations: Too long. Server-side apply avoids that. It's how Argo CD expects you to install.

Get the admin password:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d && echo

Configure Argo CD for your NGINX ingress

The browser talks HTTPS to ingress and ingress talks plain HTTP to the Argo CD server. Without this, the UI often breaks with 503 or ERR_TOO_MANY_REDIRECTS on live-update URLs (/api/v1/stream/*).

kubectl apply -f stages/stage-2-gitops/infra/argocd-cmd-params.yaml

kubectl apply -f stages/stage-2-gitops/infra/argocd-ingress.yaml

kubectl rollout restart deployment/argocd-server -n argocd

kubectl rollout status deployment/argocd-server -n argocd --timeout=180s

Expected in argocd-cmd-params-cm: server.insecure: "true", server.grpc.web: "true", server.url: https://argocd.local.

Open https://argocd.local. Login: admin and the password from above. Accept the self-signed certificate warning if the browser shows one.

Expected: The Applications page loads. In the browser console (F12 Console), you shouldn't see 401 or ERR_HTTP2_PROTOCOL_ERROR. If the UI looks fine in a normal window, you're done: incognito isn't required.

If login fails with 401 Unauthorized (often after a config change or a bad earlier login), try a private/incognito window or clear site data for argocd.local, then log in again. Still stuck? See troubleshooting.md. ArgoCD.

Connect ArgoCD to the infra repo and apply the Application manifest:

1. Edit stages/stage-2-gitops/argocd/clearledger-app.yaml

Set spec.source.repoURL to your infra repo (your GitHub username, not git config user.name).

2. Connect ArgoCD to your infrastructure repository:

This gives ArgoCD permission to watch clearledger-infra for new commits. Whenever the deployment manifests change, ArgoCD will update the cluster automatically.

# macOS: brew install argocd
argocd login argocd.local --username admin --password YOUR_PASSWORD --insecure --grpc-web

# Public repo
argocd repo add https://github.com/YOUR_USERNAME/clearledger-infra.git --grpc-web

# Private repo — PAT from Stage 1 §1.4 (you saved it as GitHub secret INFRA_REPO_TOKEN)
export INFRA_REPO_TOKEN='ghp_...'   # paste here; GitHub only shows it once at creation
argocd repo add https://github.com/YOUR_USERNAME/clearledger-infra.git \
  --username git --password "$INFRA_REPO_TOKEN" --grpc-web

Verify that Argo CD can reach the repo (do this before applying the Application):

argocd repo list --grpc-web

Look for your clearledger-infra URL with TYPE git and connection Successful. If it shows Failed or the repo is missing, Argo CD can't sync. Fix credentials before Stage 4 or any stage that depends on GitOps.

After a VM restore or Argo CD reinstall, you may need to run argocd repo add again (credentials are stored in the cluster, not in Git).

3. Apply and sync:

kubectl apply -f stages/stage-2-gitops/argocd/clearledger-app.yaml

argocd app sync clearledger --grpc-web

How to Read the Argo CD UI

After sync, open the clearledger application in the tree view. Three badges at the top tell you almost everything:

APP HEALTH: Healthy. Kubernetes thinks the workloads are running. Pods are up (or still starting if it says Progressing).

SYNC STATUS: Synced: the cluster matches clearledger-infra on GitHub at the commit shown (for example, main (2c88aa1)). Git is the source of truth and Argo CD applied it.

LAST SYNC: Succeeded: the most recent apply from Git worked. If this failed, click it for the error.

The resource tree below is the same app broken into pieces: namespace, secrets, services, deployments, ingress, and so on Green checkmarks = applied from Git. Click any box (for example, deploy/auth-service) then Live Manifest vs Desired to see what Argo CD thinks should run.

Quick "is the app actually working?" test (outside Argo CD):

curl -s -o /dev/null -w "%{http_code}\n" http://clearledger.local/auth/health

200 = the app is reachable end-to-end, not only "green in Argo CD."

When something is wrong: HEALTH goes Degraded or Progressing for a long time, SYNC goes OutOfSync, and a resource in the tree turns red. Click that resource and then Events or Logs. The kubectl checks below double-check the same thing from the terminal.

Confirm ArgoCD is watching all workloads (not only ingress):

argocd app resources clearledger --grpc-web | grep Deployment

Pass looks like your output:

apps    Deployment    clearledger    auth-service            No
apps    Deployment    clearledger    frontend                No
apps    Deployment    clearledger    ledger-service          No
apps    Deployment    clearledger    notification-service  No
apps    Deployment    clearledger    redis                   No

This command shows the Deployments that ArgoCD is managing for ClearLedger. You should see auth-service, ledger-service, notification-service, frontend, and redis. That means ArgoCD reads the full kustomization.yaml from clearledger-infra/manifests, not just one file.

The last column is ORPHANED. No is good. It means ArgoCD knows this resource belongs to the ClearLedger app. You only need to worry if one of the Deployments is missing, or if ArgoCD shows OutOfSync, Degraded, or red resources in the UI.

✋ Hands-on checkpoint: first sync healthy

Run these four checks. Pass looks like this:

kubectl get pods -n clearledger
# Every app pod 1/1 Running (postgres/redis may show older RESTARTS from VM reboots — OK)

kubectl get application clearledger -n argocd \
  -o jsonpath='sync={.status.sync.status} health={.status.health.status}{"\n"}'
# sync=Synced health=Healthy

curl -s -o /dev/null -w "%{http_code}\n" http://clearledger.local/auth/health
# 200

kubectl logs -n clearledger deploy/auth-service --tail=5 2>/dev/null | head -3
# Lines like: GET /health HTTP/1.1" 200 OK
# Bad sign: DATABASE_URL is not set

If all four pass then, Stage 2 first sync is done. Continue to Enable CI, and ArgoCD handoff below, then make check-2 and make snapshot STAGE=2.

How to Enable the CI to ArgoCD Handoff

In Stage 1, the pipeline updated clearledger-infra, but it didn't update the cluster. That was intentional.

Now ArgoCD is installed, so you can let the pipeline tell ArgoCD to check for changes after each successful run.

In GitHub, open your clearledger repo and go to Settings, Secrets and variables, Actions, Variables, and then New repository variable.

Add:

From now on, a green pipeline does two things:

1. Updates clearledger-infra with the new image tag

2. Asks ArgoCD to sync the cluster

If the pipeline can't trigger ArgoCD immediately, that's usually okay. ArgoCD checks clearledger-infra on its own every few minutes, so it should still pick up the new Git change.

Leave ENABLE_DAST unset for now. You enable that in Stage 3 after the app is stable at clearledger.local.

If the Argocd UI Shows Red Pods or "Progressing" (Read This Before the Screenshot)

This is a common first-sync surprise, not a broken install.

Why it happens in Stage 2

ArgoCD syncs whatever is in clearledger-infra. Deployments must use secretKeyRef (Stages 2–4), not Vault injection. If your infra repo has Vault annotations from an older lab copy, auth/ledger crash with DATABASE_URL is not set until Stage 5.

Network policies belong to Stage 6. In the main clearledger repo, they live in infra/deferred-by-stage/stage-6-runtime-security/netpol/, not in infra/manifests/. Don't copy them into clearledger-infra during Stage 2.

If manifests/netpol/ is still in your clearledger-infra repo on GitHub (from an older copy of the lab), ArgoCD will keep applying it. Those policies use default-deny and break DNS for new pods, so you see red 0/1 pods and Progressing health.

Fix for Stage 2

Do both steps. Deleting only in the cluster is not enough: ArgoCD recreates policies from Git on the next sync.

Step 1: remove from clearledger-infra on GitHub

Delete the folder manifests/netpol/ and commit: chore: defer network policies to Stage 6.

Step 2: sync and restart

argocd app sync clearledger --grpc-web
kubectl delete networkpolicy -n clearledger --all   # safe once Git no longer has netpol
kubectl rollout restart deployment/auth-service deployment/ledger-service -n clearledger
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"

Network policies stay in clearledger under infra/deferred-by-stage/ until you apply them in Stage 6.

When that looks good, continue below.

When ArgoCD finishes syncing, open the clearledger app in the ArgoCD UI. You should see green Healthy and Synced badges. The app should point to your clearledger-infra repo, use the manifests path, and deploy into the clearledger namespace.

Then open the app tile. The resource tree should show your deployments, services, and ingress with no red resources.

You can confirm the same thing from the terminal:

argocd app get clearledger --grpc-web

Look for Sync Status: Synced and Health Status: Healthy.

ArgoCD stuck OutOfSync

Normal path: CI copies full manifests + updates Kustomize tags, ArgoCD auto-syncs within ~3 minutes.

If still OutOfSync after 10+ minutes:

make fix-argocd

This re-syncs canonical manifests to clearledger-infra (Kustomize SHAs preserved), re-applies the Application, and triggers a hard refresh. Don't kubectl apply deployments: fix Git, let ArgoCD sync.

kubectl annotate application clearledger -n argocd 

argocd.argoproj.io/refresh=hard --overwrite

argocd app sync clearledger --grpc-web --prune

kubectl get application clearledger -n argocd -o jsonpath='sync={.status.sync.status} health={.status.health.status}{"\n"}'

Take a screenshot of that view: the app tile or the resource tree is fine. That’s your portfolio proof that GitOps is actually running.

Prove ArgoCD Self-Healing

Now prove that Git is the source of truth.

In this demo, you'll change the running cluster by hand. You will not change Git. ArgoCD should notice that the cluster no longer matches clearledger-infra, then change it back.

Before you start, make sure the app is healthy and ArgoCD is managing the deployments:

argocd app resources clearledger --grpc-web | grep Deployment

Manually change the auth-service image in the cluster:

# Manually change the image in the cluster only (Git stays the same)
kubectl set image deployment/auth-service \
  auth-service=$DOCKER_USERNAME/clearledger-auth-service:fake-tag \
  -n clearledger

Check ArgoCD:

# ArgoCD should flip to OutOfSync within a minute or two
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"

Wait for ArgoCD to fix the cluster. The fake image tag may briefly cause an image pull error. That's expected in this demo.

# Wait for selfHeal (default sync interval is ~3 minutes)
sleep 180

Confirm the image was changed back to the Git version:

# Cluster image should match clearledger-infra again — Git was never edited
kubectl get deployment auth-service -n clearledger \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

If the image changed back, ArgoCD self-healing worked. You changed the cluster by hand, but ArgoCD restored it to match clearledger-infra.

That's GitOps: Git says what should run, and ArgoCD keeps the cluster matching Git.

make check-2

How to Roll Back a Bad Deploy

You just proved that ArgoCD reverts unauthorized cluster changes. Now flip it: what if you pushed a bad commit yourself? GitOps rollback isn't a button. It's a Git operation. This section explains why, shows you both methods, and has you practice each one before you need them under pressure.

How you know you need to roll back

These symptoms appearing within minutes of a push to clearledger-infra point at a bad commit:

• Pods stuck in CrashLoopBackOff or Error. Check with kubectl get pods -n clearledger.

• kubectl logs <pod> -n clearledger --previous shows startup errors that weren't there before.

• ArgoCD health flips from Healthy to Degraded or stays on Progressing. Check with argocd app get clearledger --grpc-web.

• The app returns 5xx errors or login stops working. Check with curl -I http://clearledger.local/health.

If this happens right after a push, roll back first. Once the app is stable again, investigate the bad commit.

Why ArgoCD rollback isn't just a button

ArgoCD has a rollback button in the UI and an argocd app rollback command. Both work. But only if you understand the interaction with selfHeal.

Your Application (stages/stage-2-gitops/argocd/clearledger-app.yaml) is configured with:

syncPolicy:
  automated:
    selfHeal: true

ArgoCD keeps the cluster matched to Git. In this lab, Git means clearledger-infra.

If someone changes the cluster by hand, ArgoCD treats that as drift and changes it back to match Git.

This also affects rollback. The ArgoCD UI rollback changes the cluster, but it doesn't change Git. If clearledger-infra still points to the bad version, and self-heal can bring the bad version back.

The safer GitOps rollback is to change Git with git revert in clearledger-infra. Then ArgoCD syncs the cluster to the reverted, good version.

If you need an emergency UI rollback, turn off auto-sync first, roll back in ArgoCD, then fix Git afterward.

Method 1: Git revert (preferred, always try this first)

This is the GitOps way. You don't touch the cluster. You change Git, and ArgoCD syncs the fix.

When to use: You have a few minutes and can identify the bad commit in clearledger-infra.

How it works:

Bad commit pushed to clearledger-infra
        ↓
ArgoCD auto-synced it (cluster is now broken)
        ↓
You run: git revert <bad-commit> && git push
        ↓
ArgoCD auto-syncs the revert (cluster is fixed, selfHeal works with you)
        ↓
Git history shows the bad deploy AND the revert, full audit trail

Step-by-step:

# 1. Go to your clearledger-infra repo (wherever you cloned it)
cd ~/clearledger-infra  # adjust path if you cloned elsewhere
git pull                # make sure you are up to date

# 2. Find the bad commit
git log --oneline -10

# Output looks like:
# abc1234 update ledger-service image to v1.4.0   ← this broke prod
# def5678 update auth-service image to v1.3.1     ← was fine
# 9a1b2c3 add vault rotation cronjob

# 3. Revert it — this creates a NEW commit, it does not delete history
git revert abc1234 --no-edit

# 4. Push — ArgoCD picks it up automatically within ~3 minutes
git push

# 5. Confirm the cluster recovered
kubectl get pods -n clearledger
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Expected: Sync Status: Synced, Health Status: Healthy

This method is preferred because it fixes the source of truth: clearledger-infra.

After you push the revert, ArgoCD sees the new Git state and syncs the cluster to it. Nothing fights you because Git and the cluster are supposed to match.

It also leaves a clear history. Git shows the bad deploy, the revert, who made both changes, and when they happened. That's easier to debug, easier to review, and better for compliance.

Method 2: Emergency ArgoCD rollback (when the cluster is on fire)

Use this if the cluster is broken right now and you don't have time to push a Git fix. It pins the cluster to a previous known good deployment immediately. You'll still fix Git afterward. This isn't a permanent fix.

When to use: Incident in progress. Pods are crashing, users are affected, and you need the cluster back to a known good state in under 30 seconds.

Before you start: confirm your ArgoCD CLI session is still valid. If it expired, re-login first: an expired session will silently fail every command below.

argocd account get-user-info --grpc-web
# If you see "Unauthenticated", re-login:
ARGOCD_PASSWORD=$(kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d)

argocd login argocd.local --username admin --password "$ARGOCD_PASSWORD" \
  --insecure --grpc-web

Step 1: Disable auto-sync (critical). Skip this and selfHeal will undo your rollback within 3 minutes.

argocd app set clearledger --sync-policy none --grpc-web
# Confirm: automated sync is now off
argocd app get clearledger --grpc-web | grep "Sync Policy"
# Expected: Sync Policy: <none>

Step 2: Find the last known-good deployment ID

argocd app history clearledger --grpc-web

# Output looks like:
# ID   DATE                           REVISION
# 9    2026-06-05 10:12:00 +0000 UTC  abc1234  ← bad deploy (current)
# 8    2026-06-04 14:46:06 +0000 UTC  def5678  ← known good
# 7    2026-06-01 20:53:19 +0000 UTC  9a1b2c3

# Or check via kubectl (no argocd CLI needed):
kubectl get application clearledger -n argocd \
  -o jsonpath='{range .status.history[*]}{.id}{"\t"}{.deployedAt}{"\t"}{.revision}{"\n"}{end}'

Use the ID (the number on the left), not the SHA.

Step 3: Roll back to the good ID

argocd app rollback clearledger 8 --grpc-web

Step 4: Confirm the cluster is stable

kubectl get pods -n clearledger
# All pods should be Running

argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Sync Status:   OutOfSync  ← expected — cluster is at rev 8, Git is still at the bad HEAD
# Health Status: Healthy    ← this is what matters right now

OutOfSync is correct and expected at this point. The cluster is running the old good revision. Git still has the bad commit. You'll fix that next.

Step 5: Fix Git (don't leave it broken)

cd ~/clearledger-infra
git pull
git revert <bad-commit-sha> --no-edit
git push

Step 6: Re-enable auto-sync

argocd app set clearledger \
  --sync-policy automated \
  --self-heal \
  --auto-prune \
  --grpc-web

# Trigger an immediate sync so you do not wait for the next auto-check
argocd app sync clearledger --grpc-web

# Confirm everything is clean
argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Expected: Sync Status: Synced, Health Status: Healthy

Never leave auto-sync disabled longer than the incident. It's your drift-detection and tamper-evidence mechanism: without it, unauthorized kubectl changes go undetected. Re-enable it the moment you push the Git fix.

Practise the rollback now (before you need it under pressure)

Don't wait for a real incident to run this for the first time. The steps below simulate a bad image tag deploy and walk you through Method 1 (the preferred path).

Step 1: Push a bad image tag to clearledger-infra

cd ~/clearledger-infra
git pull

# Edit manifests/notification-service/deployment.yaml
# Change the image tag to a tag that does not exist, e.g.:
#   image: docker.io/$DOCKER_USERNAME/clearledger-notification-service:broken-tag

# Commit and push it
git add manifests/notification-service/deployment.yaml
git commit -m "test: simulate bad deploy with nonexistent image tag"
git push

Step 2: Watch ArgoCD sync the bad state

# Give ArgoCD ~3 minutes to pick it up, or trigger immediately:
argocd app sync clearledger --grpc-web

# Watch the notification-service pod fail
kubectl get pods -n clearledger -w
# You will see: notification-service pod stuck in ImagePullBackOff or ErrImagePull

Step 3: Roll back using Method 1

cd ~/clearledger-infra

# Revert the bad commit
git revert HEAD --no-edit
git push

# ArgoCD will auto-sync — or trigger it:
argocd app sync clearledger --grpc-web

# Watch pods recover
kubectl get pods -n clearledger -w
# notification-service should return to Running

Step 4: Verify

argocd app get clearledger --grpc-web | grep -E "Sync Status|Health Status"
# Expected: Sync Status: Synced, Health Status: Healthy

kubectl get pods -n clearledger
# All pods Running, no ImagePullBackOff

You have now practised a rollback end-to-end. The git revert commit is permanently in the infra repo's history: a real audit record of a simulated recovery.

Quick reference

Use Method 1 (git revert) when:

• A bad image tag or manifest was pushed to clearledger-infra and you have a few minutes

• Any config change in the infra repo caused pods to break

• This is almost always the right answer. It's fast, safe, and leaves a clean audit trail.

Use Method 2 (emergency ArgoCD rollback) when:

• The cluster is broken right now, users are affected, and you need it stable in under 30 seconds

• You're not yet sure which commit caused the problem and need time to investigate: roll back to stabilise, then use git log to find the culprit, then fix forward with Method 1

Neither method applies when a pod is crashing but nothing was pushed to the infra repo recently. This isn't a rollback problem. Check kubectl logs, Vault connectivity, and network policies instead.

revisionHistoryLimit: 10 in stages/stage-2-gitops/argocd/clearledger-app.yaml means ArgoCD always has 10 previous deployments available for emergency rollback. Increase it if your release cadence is high.

What You Learned in Stage 2

• What GitOps means: Git is the single source of truth, and a tool enforces it

• What ArgoCD does: watches Git, compares it to the cluster, corrects drift automatically

• How the full flow works now: push code, CI builds image, CI updates infra repo, and ArgoCD syncs cluster.

• No one runs kubectl to deploy anymore. The pipeline updates Git, ArgoCD does the rest.

• How to roll back safely: git revert in the infra repo is the correct answer, while ArgoCD emergency rollback is the break-glass option. You must disable auto-sync first or selfHeal will silently undo it.

What you can now put on your CV / say in an interview:

Implemented GitOps with ArgoCD so cluster state is driven from Git, with drift detection, auto-sync, and a Git-based rollback of a bad deploy.

make snapshot STAGE=2 && make snapshots. Confirm clearledger.stage2. See How to Save Your Progress.

Stage 3 — Security Gates

Every push runs security checks. Some failures stop the pipeline right away. Others you learn from now and enforce in the cluster later (Stage 4).

Goal: understand six scanners: what each one looks at, what it catches, and how to read a failure. You'll break each gate on purpose (§3.4) so a failed CI job isn't a surprise.

Ready for Stage 3?

• make check-2 passes

• ENABLE_ARGOCD_SYNC=true on GitHub (you set this in Stage 2)

• ENABLE_DAST still unset (turn on later in this stage if you want)

• Argo CD at http://argocd.local shows Synced

• Optional: skim Stage 1 security posture. Stage 1 already ran many of these tools

Done when: make check-3 passes and you triggered each gate once (§3.4). Then make snapshot STAGE=3 and make snapshots.

What You Need to Know First

One tool isn't enough. Each scanner guards a different layer:

• Gitleaks: secrets in code or Git history (API keys, tokens)

• Semgrep (SAST): bugs in your Python/JS source (injection, unsafe patterns)

• Trivy (SCA + images): finds known security vulnerabilities (called CVEs) in your Python/Node.js packages and Docker images. A CVE (Common Vulnerabilities and Exposures) is a publicly tracked software security flaw with a unique identifier.

• Checkov (IaC): misconfigurations in Dockerfiles, Kubernetes manifests, and Stage 8 Terraform.

• Cosign: proves images were built and signed by your pipeline

What blocks CI today: secrets, bad code (SAST), vulnerable images, Dockerfile issues on production images.

What waits for later: Some Kubernetes issues are only reported in Stage 1. They show you what still needs hardening. In Stage 4, Kyverno turns the important rules into real cluster enforcement, so unsafe workloads are blocked before they run.

When you git commit, hooks on your laptop can scan first (pre-commit). When you git push, GitHub Actions scans again on the runner. Same idea twice: catch mistakes before they waste a 10-minute pipeline. Pre-commit is optional to install, as CI always runs on push either way.

Enable DAST (Optional After Stage 2)

DAST (Dynamic Application Security Testing) scans the running app at http://clearledger.local. It was off in Stages 1–2 on purpose: Stage 1 never deployed to the cluster, and Stage 2 was about getting GitOps healthy first.

If make check-2 passes and curl http://clearledger.local/auth/health returns 200, you can turn DAST on:

Go to GitHub and into your clearledger repo. Then go to Settings, Secrets and variables, Actions, Variables, and New repository variable:

Push a small commit (or re-run the last workflow on main). The DAST (OWASP ZAP + fintech API tests) job should run instead of skipped. A failed ZAP scan is a real finding to investigate. Skipped before this step only means the toggle was off.

3.1: Install Pre-commit Hooks

# macOS (Homebrew — avoids PEP 668 "externally-managed-environment" from pip3):
brew install pre-commit

# Linux/WSL2:
# sudo apt install -y pre-commit
# or: python3 -m pip install --user pre-commit

pre-commit install
pre-commit run --all-files

If a hook fails, read the error first. Gitleaks and Ruff should pass before you commit. Some YAML or Terraform hook issues may come from later-stage files. If that happens, continue with the stage instructions and use troubleshooting.md for Gitleaks or CI scanner failures.

Test it catches secrets locally before CI does:

echo 'AWS_SECRET = "'$(printf '%s%s' 'AKIA' 'IOSFODNN7EXAMPLE')'"' >> app/auth-service/main.py
git add app/auth-service/main.py && git commit -m "test"

# Gitleaks fires and blocks the commit — see "What you should see" below

git restore --staged app/auth-service/main.py

git checkout app/auth-service/main.py

The commit was blocked before it even reached Git. If the pre-commit hook wasn't installed, that fake AWS key would be in your Git history permanently (even if you delete the line later, Git remembers).

If you already did Cosign in Stage 1, that counts. Stage 3 doesn't require regenerating keys. Confirm that infra/cosign.pub exists and GitHub has COSIGN_PRIVATE_KEY + COSIGN_PASSWORD. Stage 4 turns signing into enforcement at the cluster gate.

✋ Hands-on checkpoint: pre-commit actually blocks a secret

Installed-but-not-wired is the classic silent failure. Prove the hooks fire:

echo 'AWS_SECRET='"$(printf '%s%s' 'AKIA' 'IOSFODNN7EXAMPLE')" > leak-test.env

git add leak-test.env

pre-commit run --all-files; echo "exit=$?"

git reset leak-test.env >/dev/null; rm -f leak-test.env

Expected: the secret-scanning hook fails the run (exit=1) and flags leak-test.env. If exit=0, your hooks are installed but not catching anything: re-run pre-commit install and confirm .git/hooks/pre-commit exists.

If you skip this, commits sail through unscanned and you'll believe Stage 3 is protecting you when it's not.

3.2: Generate Cosign Keys

If you created Cosign keys in Stage 1 (§1.4), skip generation: go straight to inserting cosign.pub into the Kyverno policy and adding the GitHub secrets below.

Cosign signs your Docker images with a cryptographic key. When you deploy to the cluster, Kyverno (Stage 4) can verify the signature and reject any image that wasn't signed by your pipeline. This prevents someone from pushing a malicious image to your Docker Hub and having the cluster run it.

# macOS: brew install cosign

# Linux/WSL2: curl -O -L https://github.com/sigstore/cosign/releases/download/v2.2.4/cosign-linux-amd64 && chmod +x cosign-linux-amd64 && sudo mv cosign-linux-amd64 /usr/local/bin/cosign

cosign generate-key-pair   # enter a password when prompted

This creates two files: cosign.key (private, used by the pipeline to sign) and cosign.pub (public, used by Kyverno to verify).

Insert your public key into the Kyverno policy (replace the placeholder block in infra/policies/require-signed-images.yaml with the contents of cosign.pub).

Add secrets to GitHub (github.com/YOUR_USERNAME/clearledger → Settings → Secrets and variables → Actions):

✋ Hands-on checkpoint: Cosign keys are ready

Stage 4 uses cosign.pub to verify signed images. Before you continue, confirm the key files exist and the private key isn't tracked by Git:

test -f cosign.key && echo "private key present"
test -f cosign.pub && echo "public key present"
grep -q "BEGIN PUBLIC KEY" cosign.pub && echo "public key valid"
git check-ignore cosign.key && echo "private key correctly ignored"

Expected: all four lines should print.

If git check-ignore cosign.key prints nothing, add cosign.key to .gitignore before committing anything. The private key must stay out of Git.

Don't skip this check. Stage 4 needs the public key for the Kyverno image-signing policy, and the private key must remain local.

3.3: Activate the Full Security Pipeline

The security gates are already in .github/workflows/ci.yaml. Push any change to trigger the full pipeline:

git add . && git commit -m "ci: full DevSecOps pipeline" && git push origin main

3.4: Break Each Gate on Purpose

For each gate, you'll want to break something on purpose, read how the tool reports it, revert, and confirm green again. Try the local command first, then push once if you want a screenshot on GitHub Actions.

# 1. Break it   2. Run locally or push   3. Read the failure
# 4. git checkout -- path/to/file   5. pre-commit run --all-files (optional)   6. git push

Start with Gate 1 end-to-end before the others.

Gate 1: Gitleaks (secrets)

Inject: hardcoded AWS key in any Python file.

The goal is to prove the secret scanner works.

This command adds a fake AWS-looking key to app/auth-service/main.py:

echo 'AWS_KEY = "'$(printf '%s%s' 'AKIA' 'IOSFODNN7EXAMPLE')'"' >> app/auth-service/main.py

git add app/auth-service/main.py && git commit -m "test: trigger gitleaks"
# pre-commit blocks this commit locally — that is the test.
# For a CI screenshot only: git commit --no-verify -m "test: trigger gitleaks" && git push

Done looks like this (terminal: pre-commit):

🔑 Secrets scan (Gitleaks)...............................................Failed
- hook id: gitleaks
- exit code: 1

Finding:     AWS_KEY = "REDACTED"
RuleID:      aws-access-token
File:        app/auth-service/main.py
Line:        316

Expected: the commit should fail. Gitleaks should report one secret finding in app/auth-service/main.py.

That failure is good. It means the local pre-commit hook caught the secret before it reached Git.

Revert:

git restore --staged app/auth-service/main.py 2>/dev/null
git checkout app/auth-service/main.py
pre-commit run gitleaks --all-files   # → Passed

Gate 2: Semgrep (SAST)

Local dry-run (no repo change):

python3 -m venv /tmp/sec-gates-venv && /tmp/sec-gates-venv/bin/pip install semgrep
cat > /tmp/semgrep-bad.py << 'EOF'
import subprocess
from fastapi import Request
def bad(request: Request):
    subprocess.run(request.query_params.get("cmd"), shell=True)
EOF
/tmp/sec-gates-venv/bin/semgrep \
  --config=p/python --config=p/security-audit --config=p/owasp-top-ten --error \
  /tmp/semgrep-bad.py

Break CI: add a temporary file Semgrep will scan, commit, and push:

cat > app/auth-service/gate_test_semgrep.py << 'EOF'
import subprocess
from fastapi import Request
def bad(request: Request):
    subprocess.run(request.query_params.get("cmd"), shell=True)
EOF

git add app/auth-service/gate_test_semgrep.py && git commit -m "test: trigger semgrep" && git push

Expected result: Semgrep reports subprocess-shell-true as Blocking. The SAST (Semgrep) job turns red, and the image build jobs don't run.

Revert:

rm -f app/auth-service/gate_test_semgrep.py
git add -A && git commit -m "revert: semgrep gate test" && git push

Gate 3: Checkov (IaC / Dockerfile)

Checkov scans Dockerfiles and Kubernetes manifests for unsafe configuration.

First, run a local demo. This removes the HEALTHCHECK from a copied Dockerfile and shows how Checkov reports it:

python3 -m venv /tmp/sec-gates-venv && /tmp/sec-gates-venv/bin/pip install checkov
sed '/^HEALTHCHECK/,+1d' app/auth-service/Dockerfile > /tmp/Dockerfile-nohc
mkdir -p /tmp/checkov-demo/app/auth-service
cp /tmp/Dockerfile-nohc /tmp/checkov-demo/app/auth-service/Dockerfile
/tmp/sec-gates-venv/bin/checkov --directory /tmp/checkov-demo --framework dockerfile

Now trigger a Checkov finding in CI by exposing SSH port 22 in the auth-service Dockerfile:

echo 'EXPOSE 22' >> app/auth-service/Dockerfile
git add app/auth-service/Dockerfile && git commit -m "test: trigger checkov" && git push

Expected result: the Checkov log or artifact should show CKV_DOCKER_1, which means an SSH port was exposed.

The IaC Scan (Checkov) job may or may not turn red, depending on the severity Checkov assigns. That's okay for this exercise. The goal is to find and understand the Checkov result.

If you need a screenshot of a failed GitHub Actions job, use Gate 1, Gate 2, or Gate 4. Those are designed to turn the workflow red. Checkov is mainly for reading the finding, so it may stay green.

Revert:

git checkout app/auth-service/Dockerfile
git commit -am "revert: checkov gate test" && git push

Gate 4: Trivy (image CVEs)

Local dry-run: scan an old base image (no build):

trivy image --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed python:3.8-slim

Break CI: pin an old base in the Dockerfile, push, wait for Scan images:

sed -i.bak 's/FROM python:3.13-slim/FROM python:3.8-slim/' app/auth-service/Dockerfile
git add app/auth-service/Dockerfile && git commit -m "test: trigger trivy" && git push

Pass: Scan images → Trivy scan all images exits 1 with a CVE table (HIGH / CRITICAL). Publish images and Update Manifests are skipped.

Revert:

git checkout app/auth-service/Dockerfile
git commit -am "revert: trivy gate test" && git push

3.5: When a Scan Fails on a CVE You Didn't Inject

§3.4 is deliberate. This section is for the other case where you push normal code, but the image scan fails because a new vulnerability was found.
That's normal. CVE databases update all the time. Don't weaken the scan. Fix the vulnerable package or image.

First, find the real CVE. In GitHub Actions, open Scan images then go to Trivy scan all images and look for the table with:

• Package

• CVE

• Installed version

• Fixed version You can also download the artifact:

Ignore this red herring at the bottom of the log:

Version 0.71.2 of Trivy is now available
Error: Process completed with exit code 1.

The version notice doesn't fail the job. A fixable HIGH/CRITICAL CVE does. Don't add --skip-version-check to “fix” it.

Instead, fix it with:

• pip package: bump to the Fixed Version in requirements.txt (example: python-multipart==0.0.30 for CVE-2026-53539). Apply the same bump to sibling services if they share that pin.

• OS package: newer base image or a targeted apt/apk upgrade in the Dockerfile.

• No stable fix yet documented exception only: add the CVE to .trivyignore and .grype.yaml with a comment (see CVE-2026-7210).

Don't remove --exit-code 1, lower the severity rule, or disable scanning. For help, see Trivy version notice and Trivy blocks Python service images.

Finish Stage 3

For screenshots, use one clear failed gate:

• Gitleaks: Secrets Scan

• Semgrep: SAST

• Trivy: Scan images

• Checkov: look for CKV_* in the log or artifact. The job may stay green

After each test in §3.4, undo the test change, push the revert, and confirm the workflow is green again. One red GitHub Actions screenshot is enough for your portfolio.

Run the stage check:

make check-3   # must end: All checks passed. Ready for the next stage.

Expected: All checks passed. Ready for the next stage.

You should also have triggered at least one gate in §3.4. A local Gitleaks failure counts.

ENABLE_DAST=true is optional. You only need it if you want to run ZAP later.

Not required yet: Checkov blocking Kubernetes manifests or Cosign blocking deployments. Stage 4 turns those into cluster enforcement with Kyverno.

Next, save your progress:

make snapshot STAGE=3 && make snapshots

Stage 4 — Admission Control (Kyverno)

Even if CI passes, the cluster can still refuse.

CI scans your code and images before they reach GitOps, but it can't watch everything that happens inside the cluster. Someone with kubectl access could apply a manifest directly.

A Helm chart you install might create pods that violate your security standards. Those paths never hit the pipeline, which is why Stage 4 adds admission control: a checkpoint built into Kubernetes itself.

Every time something tries to create or update a resource, the request passes through admission webhooks before it takes effect. If a webhook rejects the request, the resource is never created.

Kyverno is a Kubernetes-native policy engine that uses those webhooks. You write policies as YAML files (not application code), and Kyverno enforces them on every matching resource in the cluster, for example, rejecting any pod that runs as root or requiring CPU and memory limits on every container.

The difference from CI is timing: CI scans before code ships, while Kyverno enforces at the cluster gate. Together they give you two layers of defense.

Your goal in this stage is to install Kyverno, apply the policies in infra/policies/, and prove in §4.4 that non-compliant pods are denied before the container runtime ever sees them.

Before you start, make sure the foundation from earlier stages is still solid: make check-3 should pass (pre-commit hooks and CI security gates are active), infra/cosign.pub should exist from Stage 3, and ArgoCD should still be syncing so the app responds at http://clearledger.local. If any of those are red, fix them first: Kyverno sits on top of a healthy cluster, not a broken one.

You're done with Stage 4 when all three break-it scenarios in §4.4 are denied and make check-4 passes.

What changes from Stage 3 is enforcement, not scanning. In CI, Checkov reported Kubernetes misconfigurations but didn't block the pipeline. Kyverno now stops those same classes of problems at the cluster gate.

Cosign has been signing your images since Stage 1. Kyverno now requires that signature before a ClearLedger image can deploy. This is where Stage 1 evidence becomes enforcement. See that section if you want the full map of what blocked in Stage 1 versus what waited for Stage 4.

Start with §4.1 to install Kyverno. If the install, policies, break-it scenarios, or make check-4 fail, read troubleshooting.md and Stage 4: Admission Control (Kyverno) before changing Helm values or policy YAML.

What Kyverno Enforces

All policy files live in infra/policies/. Kyverno itself is installed via Helm using stages/stage-4-admission-control/infra/kyverno/values.yaml.

Platform Stability: From Stage 4 Onward

From Stage 4 on, you're running more controllers on a single-node VM. Kyverno, storage provisioners, and later Prometheus and Loki. A pod can show Running while it's actually crash-looping in the background.

When platform pods (Kyverno controllers, hostpath-provisioner, the Prometheus operator, and similar) accumulate high RESTARTS, the API server starts timing out, kubectl feels flaky, and you can waste days debugging the wrong component because the app pods look fine.

After every stage from here on, give the cluster about ten minutes to settle, then run the stage health check:

bash scripts/health-check.sh <stage>    # for example, 4, 7, 7.5
# or the Makefile shortcut:
make check-4

The script ends with a Platform stability section that flags pods with suspicious restart counts. You can also scan the worst offenders yourself. This lists the fifteen pods with the highest restart counts cluster-wide, which is useful when something feels slow but you're not sure which namespace is struggling:

kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount' \
  -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount' \
  | tail -15

The gate: Kyverno controllers and other platform pods should show RESTARTS under 5 after the stage settles. If any platform pod is climbing past 10, stop and fix it with the documented Helm values or troubleshooting.md. Don't kubectl patch around it and move on. A stable platform layer is a prerequisite for every stage that follows.

4.1: Install Kyverno

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm upgrade --install kyverno kyverno/kyverno \
  --version 3.2.8 \
  --namespace kyverno \
  --create-namespace \
  -f stages/stage-4-admission-control/infra/kyverno/values.yaml \
  --wait --timeout=600s

The values file does three important things for the lab:

1. Disables cleanup CronJobs: older Kyverno charts pull bitnami/kubectl, which was removed from Docker Hub and causes ImagePullBackOff on cleanup pods.

2. Points Helm hooks at bitnamilegacy/kubectl, so future helm uninstall doesn't hang on a missing image.

3. Extends liveness probe timeouts: the default timeoutSeconds: 5, failureThreshold: 2 is too tight for a loaded single-node VM. Under CPU pressure, the health endpoint can take >5s to respond, which triggers a restart cascade that saturates the node and makes the API server intermittently unreachable. The values file sets timeoutSeconds: 30, failureThreshold: 5 so Kyverno survives load spikes without crash-looping.

What you should see:

Release "kyverno" does not exist. Installing it now.
NAME: kyverno
NAMESPACE: kyverno
STATUS: deployed
...
Kyverno version: v1.12.6

Verify all four controllers are running (first pull can take several minutes on a slow connection):

kubectl get pods -n kyverno

NAME                                             READY   STATUS    RESTARTS   AGE
kyverno-admission-controller-bd685cd4b-f6kl6     1/1     Running   0          2m
kyverno-background-controller-66fcfc6d87-59wgt   1/1     Running   0          2m
kyverno-cleanup-controller-5c5bf8bc6b-7kspq      1/1     Running   0          2m
kyverno-reports-controller-5cdd6f4c48-qf5wc      1/1     Running   0          2m

If pods stay in ContainerCreating for a long time, the node is still pulling images from ghcr.io/kyverno. Wait. Don't start a second Helm install on top of a partial one.

Stability gate: Kyverno install only (before §4.2):

Before continuing, make sure the Kyverno pods are healthy:

kubectl get pods -n kyverno

Expected: the Kyverno controller pods show 1/1 Running, with low restart counts such as 0, 1, or 2, and the restart count isn't increasing.

Don't run make check-4 yet. That check also looks for the policies you apply later in §4.3, so it may fail at this point even if Kyverno installed correctly.

4.2: Confirm your Cosign Public Key is in the Policy

Stage 3 created infra/cosign.pub. Kyverno uses that same key to verify image signatures when a pod is created. The policy file ships with a placeholder. You must replace it with your key before applying policies in §4.3.

Step 1: Show your key (run from the repo root on the VM)

cd ~/clearledger    # or wherever you cloned the repo
cat infra/cosign.pub

You should see three lines: -----BEGIN PUBLIC KEY-----, a long base64 line, and -----END PUBLIC KEY-----. Copy that whole block (you'll paste it in the next step).

Step 2: Paste the key into the policy

Open infra/policies/require-signed-images.yaml in your editor (nano, vim, or VS Code).

Find this line:

                      PASTE_YOUR_COSIGN_PUBLIC_KEY_HERE

Delete only that placeholder line and paste the three lines from cosign.pub in its place. The result should look like this (your base64 line will differ):

                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                     JFkwEwYHKoZIzj0CAQYIKoFIzj0DAQcDQgZEI...
                      -----END PUBLIC KEY-----

Save the file. Keep the pasted key indented under publicKeys: |-. The BEGIN PUBLIC KEY and END PUBLIC KEY lines should have spaces before them, just like the base64 line between them.

Step 3: Verify (three quick checks)

Run these one at a time from the repo root:

# Check A — placeholder must be gone
grep PASTE_YOUR_COSIGN_PUBLIC_KEY_HERE infra/policies/require-signed-images.yaml \
  && echo "❌ FAIL: placeholder still in file — edit and save again" \
  || echo "✓ OK: placeholder removed"

# Check B — key block must be present exactly once
grep -c "BEGIN PUBLIC KEY" infra/policies/require-signed-images.yaml

Expected output for Check B: 1 (if you see 0, the key was not pasted. If 2, you pasted it twice).

# Check C — policy key must match cosign.pub byte-for-byte
diff infra/cosign.pub \
  <(sed -n '/-----BEGIN PUBLIC KEY-----/,/-----END PUBLIC KEY-----/p' \
      infra/policies/require-signed-images.yaml | sed 's/^[[:space:]]*//')

Expected output for Check C: nothing. No diff lines means the keys match. If diff prints differences, open the policy file and fix the paste.

If all three passed, continue to §4.3.

If you skip this, Scenario 3 in §4.4 fails in a confusing way: unsigned images may slip through, or signed pods may be rejected because Kyverno is checking against the wrong key.

4.3: Apply the Five Core Policies

Now you'll apply the five policies that map to CIS controls. Don't apply verify-slsa-provenance.yaml yet. It's an optional SLSA attestation policy (Audit mode) for a later enhancement.

Stage 4 applies infra/policies/require-signed-images.yaml. This policy uses failurePolicy: Fail, so if Kyverno can't verify an image signature, the pod is blocked instead of allowed. The ECR policy with failurePolicy: Ignore is for Stage 8, not this step.

kubectl apply \
  -f infra/policies/disallow-root.yaml \
  -f infra/policies/disallow-privilege-escalation.yaml \
  -f infra/policies/drop-all-capabilities.yaml \
  -f infra/policies/require-resource-limits.yaml \
  -f infra/policies/require-signed-images.yaml

Wait a few seconds, then confirm all policies show READY: True and VALIDATE ACTION: Enforce:

kubectl get clusterpolicy

NAME                            ADMISSION   BACKGROUND   VALIDATE ACTION   READY   AGE
disallow-privilege-escalation   true        true         Enforce           True    10s
disallow-root-containers        true        true         Enforce           True    10s
drop-all-capabilities           true        true         Enforce           True    10s
require-resource-limits         true        true         Enforce           True    10s
require-signed-images           true        false        Enforce           True    10s

If READY stays empty, check Kyverno logs: kubectl logs -n kyverno -l app.kubernetes.io/component=admission-controller --tail=50.

4.4: Breaking it on Purpose

Now you'll test the policies by trying to create bad pods.

These pods are supposed to fail. That's the point.

CI tools like Checkov warn you in a report. Kyverno goes further: it blocks unsafe pods before Kubernetes runs them.

For each test, read the error message, as it should tell you which policy blocked the pod and what field was wrong. That error message is your proof that admission control is working.

Scenario 1: root container (no securityContext)

What you're simulating: Someone with kubectl access bypasses CI and applies a minimal pod: no securityContext, no resource limits.

This is exactly what Stage 1 Checkov flagged as evidence. Stage 4 now blocks it.

What's wrong with this manifest: The container has only a name and image. It will run as root by default, keep all Linux capabilities, and has no CPU/memory bounds.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: root-test
  namespace: clearledger
spec:
  containers:
    - name: test
      image: nginx:alpine
EOF

What you should see:

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/clearledger/root-test was blocked due to the following policies

disallow-privilege-escalation:
  check-allowPrivilegeEscalation: 'validation error: allowPrivilegeEscalation must
    be set to false. rule check-allowPrivilegeEscalation failed at path /spec/containers/0/securityContext/'
disallow-root-containers:
  check-runAsNonRoot: |-
    validation error: Root containers are blocked in the clearledger namespace. Set securityContext.runAsNonRoot: true on the pod or container.
    . rule check-runAsNonRoot failed at path /spec/containers/0/securityContext/
drop-all-capabilities:
  check-capabilities: 'validation error: All containers must drop ALL capabilities.
    rule check-capabilities failed at path /spec/containers/0/securityContext/'
require-resource-limits:
  check-resources: 'validation error: Resource requests and limits are required for
    all containers. rule check-resources failed at path /spec/containers/0/resources/limits/'

How to read this output:

The important line is:

resource Pod/clearledger/root-test was blocked due to the following policies

That means Kyverno stopped the pod before it was created.

Under that line, Kyverno lists every policy the pod failed. For example:

disallow-root-containers:
  check-runAsNonRoot:

This means the pod failed the disallow-root-containers policy, specifically the check-runAsNonRoot rule. The fix is also shown in the message:

Set securityContext.runAsNonRoot: true

The same pattern applies to the other policies:

• disallow-privilege-escalation means the pod didn't set allowPrivilegeEscalation: false

• drop-all-capabilities means the pod didn't drop Linux capabilities with capabilities.drop: [ALL]

• require-resource-limits means the pod didn't set CPU and memory requests/limits

The path part tells you where Kubernetes expected the missing setting. For example, /spec/containers/0/securityContext/ means: look inside the pod spec, then the first container, then its securityContext.

And /spec/containers/0/resources/limits/ means: look inside the first container's resource limits.

So this one bad pod failed four controls at once. That's the lesson: Kyverno doesn't just say "no." It tells you which policy failed and where to fix the YAML.

Verify enforcement worked:

kubectl get pod root-test -n clearledger
# Error from server (NotFound): pods "root-test" not found

If you see a pod in Running or Pending, policies aren't enforcing: re-check that kubectl get clusterpolicy shows all five READY: True.

Take a screenshot. This is portfolio evidence for CIS Kubernetes Benchmark 5.2.6: enforced, not just configured.

Scenario 2: missing resource limits

What you're simulating: A developer who read the securityContext requirements and fixed root/caps/privilege. But skipped resource limits.

This is common in real teams: “we hardened the container” but forgot CPU/memory bounds.

What's wrong with this manifest: securityContext is correct, but there's no resources.requests or resources.limits. A container without limits can starve other workloads on the node.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: nolimits-test
  namespace: clearledger
spec:
  containers:
    - name: test
      image: nginx:alpine
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
EOF

What you should see:

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/clearledger/nolimits-test was blocked due to the following policies

require-resource-limits:
  check-resources: 'validation error: Resource requests and limits are required for
    all containers. rule check-resources failed at path /spec/containers/0/resources/limits/'

Key observation: Only one policy fires this time: the securityContext fields satisfied the other four rules. Kyverno evaluates rules independently. Each container property is a separate gate.

Verify:

kubectl get pod nolimits-test -n clearledger
# Error from server (NotFound): pods "nolimits-test" not found

Scenario 3: unsigned ClearLedger image

What you're simulating: A supply-chain attack: someone pushes a malicious image to Docker Hub under your repo name (clearledger-auth-service) without going through your signed CI pipeline. Stage 3 made Cosign signing possible, while Stage 4 makes it mandatory at the cluster gate.

Why this setup is needed: Kyverno checks image signatures against the image in Docker Hub, not against images on your laptop. The test image tag must exist in Docker Hub first.

If you use a fake tag like :unsigned that was never pushed, Kubernetes may fail later with ImagePullBackOff. That only means the image can't be pulled; it doesn't prove Kyverno blocked an unsigned image.

Step 1: push a deliberately unsigned test image (one-time):

export DOCKER_USERNAME=your-dockerhub-username

docker pull nginx:alpine
docker tag nginx:alpine ${DOCKER_USERNAME}/clearledger-auth-service:unsigned-test
docker push ${DOCKER_USERNAME}/clearledger-auth-service:unsigned-test

# Must fail — proves the image has no Cosign signature from your pipeline key:
cosign verify --key infra/cosign.pub \
  index.docker.io/${DOCKER_USERNAME}/clearledger-auth-service:unsigned-test
# Error: no signatures found

Step 2: try to deploy it with a compliant pod spec:

The pod manifest is fully hardened (securityContext + limits) so only the signature policy can fail. Use index.docker.io/ in the image URL: on Kyverno 1.12, docker.io/... may not trigger verifyImages matching.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: unsigned-test
  namespace: clearledger
spec:
  containers:
    - name: test
      image: index.docker.io/${DOCKER_USERNAME}/clearledger-auth-service:unsigned-test
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          drop: [ALL]
      resources:
        requests:
          memory: "64Mi"
          cpu: "50m"
        limits:
          memory: "128Mi"
          cpu: "200m"
EOF

What you should see:

Error from server: error when creating "STDIN": admission webhook "mutate.kyverno.svc-fail" denied the request:

resource Pod/clearledger/unsigned-test was blocked due to the following policies

require-signed-images:
  verify-cosign-signature: 'failed to verify image index.docker.io/veeno-demo/clearledger-auth-service:unsigned-test:
    .attestors[0].entries[0].keys: no signatures found'

How to read this output:

• Note the webhook name is mutate.kyverno.svc-fail, not validate: image verification runs in Kyverno’s mutate pass (digest + signature check) before the pod is admitted.

• no signatures found means Kyverno reached Docker Hub, found the image, and confirmed it was not signed with your infra/cosign.pub key.

• The pod never exists: the attacker can't get a shell even if the image is pullable.

Verify:

kubectl get pod unsigned-test -n clearledger
# Error from server (NotFound): pods "unsigned-test" not found

What you should NOT see (these mean the test didn't prove signature enforcement):

Contrast: signed image is allowed:

The previous test used an unsigned image, so Kyverno blocked it.

Your real ClearLedger images should be signed by the CI pipeline. If the pod also follows the security rules, Kyverno allows it to run.

You can check the image currently used by auth-service:

# Your deployed tag (signed in CI) should start if spec is compliant:
kubectl get deployment auth-service -n clearledger \
  -o jsonpath='{.spec.template.spec.containers[0].image}'
# docker.io/veeno-demo/clearledger-auth-service:v0.1.0

Example output:

docker.io/veeno-demo/clearledger-auth-service:v0.1.0

Pods that were already running before the policies were applied will keep running. The important test is what happens when Kubernetes creates a new pod. New pods using signed ClearLedger images should pass Kyverno verification.

Take a screenshot of the Scenario 3 denial. It proves the cluster blocks unsigned images, not just that CI signs images.

4.5: Verify ClearLedger Still Works

Kyverno enforces on new pod creation. Existing deployments that already passed admission (or were synced before policies existed) keep running. Confirm your app pods are healthy:

kubectl get pods -n clearledger

NAME                                    READY   STATUS    RESTARTS   AGE
auth-service-...                        1/1     Running   0          ...
frontend-...                            1/1     Running   0          ...
ledger-service-...                      1/1     Running   0          ...
notification-service-...                1/1     Running   0          ...
postgres-0                              1/1     Running   0          ...
redis-...                               1/1     Running   0          ...

If ingress is configured:

curl -s http://clearledger.local/auth/health | jq .
# {"status": "ok", "service": "auth-service"}

ArgoCD should still show Synced and Healthy: GitOps and admission control work together, not against each other.

4.6: Policy Exceptions (When a Legitimate Workload Needs a Bypass)

Kyverno blocks every pod that violates a policy. But what happens when a legitimate workload needs to bypass a specific rule?

PostgreSQL is the example. The official Postgres Alpine image uses a specific internal user (UID 70) to manage its data directory. The disallow-root-containers policy requires every pod to set runAsNonRoot: true.

Postgres does set that. But if Kyverno is configured to also check specific UID ranges, or if the pod's security context doesn't satisfy the rule for any reason, Kyverno blocks it. The database can't start, and the entire application fails.

You can't weaken the policy cluster-wide to accommodate one database. That would let every pod bypass the rule. Instead, you create a PolicyException: a targeted exemption for exactly the pods that need it.

Open infra/policies/exceptions/postgres-root-exception.yaml and read the comments. Here's what each section does:

The spec.exceptions block identifies which policy and rule to bypass:

exceptions:
  - policyName: disallow-root-containers
    ruleNames:
      - check-runAsNonRoot

This says: "skip only the check-runAsNonRoot rule from the disallow-root-containers policy." Every other rule in that policy (and every other policy in the cluster) still enforces normally.

The spec.match block limits which resources get the exception:

match:
  any:
    - resources:
        kinds:
          - Pod
        namespaces:
          - clearledger
        names:
          - postgres-*

Only pods named postgres-* (matching postgres-0, postgres-1, and so on), only in the clearledger namespace, only for the Pod resource kind. Everything else in the cluster still follows the strict policy.

The annotations are documentation for your team and auditors:

annotations:
  reason: "Postgres alpine image requires UID 70 for data directory ownership"
  approved-by: "platform-team"
  review-date: "2026-01-01"

These have no technical effect: Kyverno ignores them. They exist so that six months from now, when someone asks "why does Postgres bypass this rule?", the answer is right there in the file.

The rules for safe exceptions:

1. Scope narrowly: target the exact resource that needs it, nothing more

2. Commit to Git: the exception is reviewed in a pull request, tracked in version history, and auditable

3. Never weaken the policy itself: the rule stays strict for everything else

4. Review periodically: exceptions should be temporary if possible, and re-evaluated on a schedule

Apply the exception only if Kyverno blocks your Postgres pods:

kubectl apply -f infra/policies/exceptions/postgres-root-exception.yaml

Verify Kyverno still blocks other non-compliant pods (same denial as Scenario 1):

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: another-root-test
  namespace: clearledger
spec:
  containers:
    - name: test
      image: nginx:alpine
EOF

4.7: CIS Benchmark Evidence kube-bench)

You already installed Kyverno and proved it blocks unsafe pods.

This step is different. kube-bench doesn't block pods and doesn't change the cluster. It only checks the Kubernetes node against the CIS benchmark and saves evidence.

Think of the difference like this:

Both are useful, but only Kyverno blocks workloads in this lab.

Run kube-bench:

bash stages/stage-4-admission-control/scripts/run-kube-bench.sh

The script runs kube-bench as a Kubernetes Job and saves the report here:

stages/stage-4-admission-control/scripts/kube-bench-report.json

It also compares the result against this baseline:

stages/stage-4-admission-control/scripts/kube-bench-baseline.json

On MicroK8s, you'll see many FAIL and WARN lines. That's expected. The lab isn't asking you to fix every CIS warning on a single-node local VM.

What matters is the final result.

Pass looks like this:

kube-bench: 1 FAIL control(s) present (documented in baseline — no regressions).
kube-bench: no regressions vs baseline.

That means the known MicroK8s issues are documented, and your cluster didn't get worse.

If you see REGRESSION or make check-4 fails on kube-bench, stop and investigate before Stage 5.

Optional: confirm the report file exists:

ls -la stages/stage-4-admission-control/scripts/kube-bench-report.json

In production, you would either fix the CIS failures or document approved exceptions. In this lab, the baseline records the expected MicroK8s state.

4.8: Health Check

make check-4

What you should see:

▶ Stage 4 — Admission Control (Kyverno)
  ✓ Kyverno is running
  ✓ Policy disallow-root-containers — Enforce mode
  ✓ Policy require-resource-limits — Enforce mode
  ✓ Policy require-signed-images — Enforce mode
  ✓ Policy disallow-privilege-escalation — Enforce mode
  ✓ Policy drop-all-capabilities — Enforce mode
  ✓ Kyverno correctly rejects pods without securityContext
  ✓ kube-bench baseline exists (...)

All checks passed. Ready for the next stage.

If kube-bench reports regressions, run the script manually and update the baseline after reviewing. That diff is audit evidence.

If Kyverno install, policies, break-it scenarios, or make check-4 fail, see troubleshooting.md. Stage 4.

Stage 4 Complete: Done Checklist (Move to Stage 5)

You're done with Stage 4 when all of these are true:

Portfolio screenshots (optional): root-pod denial (§4.4 Scenario 1), unsigned-image denial (§4.4 Scenario 3), and kubectl get clusterpolicy showing five Enforce policies.

Not yet: SLSA attestation (optional), Vault secrets (Stage 5), network policies (Stage 6). Passwords still live in Kubernetes Secrets. Stage 5 moves them into Vault.

What You Learned in Stage 4

• The difference between CI scanning (before merge) and admission control (at the cluster gate)

• What Kyverno is: a policy engine that intercepts every Kubernetes API request

• That enforcement means the bad resource never exists, not "we detected it after the fact"

• How to read a Kyverno denial: policy name → rule name → JSON path that failed

• How to write and apply cluster-wide security policies as YAML

• How to scope a PolicyException without weakening the policy for everyone else

• That operational issues (Helm, image pulls, registry URL format) affect whether controls actually fire

• Why both CI and admission control are needed: CI catches problems in your code while Kyverno catches everything else that touches the cluster

• Evidence beats configuration: a policy file in Git means nothing: the break-it denials are proof CIS controls are enforced, not just documented.

What you can now put on your CV / say in an interview:

Enforced admission control with Kyverno: blocking root containers, privilege escalation, unsigned images, and missing resource limits at deploy time: mapped to CIS Kubernetes benchmarks.

make snapshot STAGE=4 && make snapshots. Confirm clearledger.stage4. See How to Save Your Progress.

Stage 5: Secrets Management (Vault)

By the end of this stage, sensitive values no longer live in Git or in etcd-backed Kubernetes Secrets: Vault holds them centrally and injects them into pods only when they start.

Your goal: remove auth-service-secret and ledger-service-secret from the cluster.

Login and API calls must still work because Vault injects credentials at pod startup. That's the moment secrets management clicks.

Before you start, confirm Stage 4 is solid: make check-4 passes, all five Kyverno policies are enforcing, and the app responds at http://clearledger.local. Fix any crash-looping pods before installing Vault.

What Changes in This Stage

Right now, database passwords and JWT keys sit in secret.yaml files on GitHub and in Kubernetes Secrets inside the cluster. In Stage 5 you move those values into HashiCorp Vault and teach the app to read them a different way.

When an auth or ledger pod starts, the Vault agent injector adds a small sidecar container. That sidecar logs into Vault using the pod’s own service account, fetches the password and JWT, and writes them as files under /vault/secrets/.

Your app already knows how to read those paths. It's the same data that used to arrive via secretKeyRef, just delivered at runtime instead of pulled from a Kubernetes Secret object.

Once migration is complete, sensitive values live in Vault (the long-term store) and briefly on the pod filesystem while the container runs. They're not in Git anymore. You remove secret.yaml from clearledger-infra and ArgoCD syncs deployments that point at Vault instead.

To load Vault the first time, you copy a template to a local .env file (§5.1). That file is gitignored. You run seed-vault-secrets.sh once to copy those values into Vault.

Real secret values aren't written into committed scripts. The scripts read secrets from your local .env file or from your terminal, so passwords and tokens stay out of Git.

Do the Steps in This Order

Each step depends on the one before it. Skipping ahead is the most common way to get red auth/ledger pods that look like a broken app but really mean “Vault is not ready yet.”

1. §5.1: copy stages/stage-5-secrets-management/.env.example to .env, then fill it with your cluster passwords

2. §5.2: install Vault and the agent injector with Helm

3. §5.3. Run setup.sh, then seed-vault-secrets.sh (passwords now live in Vault)

4. §5.4: push Vault-enabled deployments to clearledger-infra. Let ArgoCD sync.

5. §5.5. Wait for 2/2 pods (app + Vault sidecar), then delete the old Kubernetes Secrets

6. §5.5b: ArgoCD Synced / Healthy (after secret delete. OutOfSync before delete is normal)

7. §5.6. Confirm login works and credentials appear under /vault/secrets/ inside the pod

Start at §5.1. If anything fails, read troubleshooting.md. before changing manifests.

5.1: Create .env (Local Only, Never Commit)

This file holds two things: a dev Vault root token for Helm (§5.2), and the passwords you'll load into Vault in §5.3.

It stays on your machine only. Never commit it. The SEED_* values must match what the app uses today so login still works after you delete Kubernetes Secrets later.

Two different files. Don't mix them up:

The sample block at the bottom of this section is only a picture of what a completed .env looks like: don't copy those placeholder passwords unless they happen to match your cluster.

Step 1: copy the template to .env

cp stages/stage-5-secrets-management/.env.example \
   stages/stage-5-secrets-management/.env

That gives you a file with empty VAULT_TOKEN= and SEED_*= lines. Open it in your editor for steps 2–3.

Step 2: read the current passwords from the cluster

Run these from the repo root. Each command prints one value: copy the output into .env in step 3.

# → paste as SEED_AUTH_DATABASE_URL
kubectl get secret auth-service-secret -n clearledger \
  -o jsonpath='{.data.database_url}' | base64 -d; echo

# → paste as SEED_AUTH_JWT_SECRET
kubectl get secret auth-service-secret -n clearledger \
  -o jsonpath='{.data.jwt_secret}' | base64 -d; echo

# → paste as SEED_LEDGER_DATABASE_URL
kubectl get secret ledger-service-secret -n clearledger \
  -o jsonpath='{.data.database_url}' | base64 -d; echo

Step 3: fill in .env

Sample only: shape of a completed .env (use your kubectl output from step 2, not these example strings unless they match):

VAULT_TOKEN=my-dev-root-token
SEED_AUTH_DATABASE_URL=postgresql://clearledger:changeme-stage0@postgres:5432/clearledger
SEED_AUTH_JWT_SECRET=stage0-jwt-secret-change-in-production
SEED_LEDGER_DATABASE_URL=postgresql://clearledger:changeme-stage0@postgres:5432/clearledger

If auth-service-secret is already deleted (you skipped ahead: recover like this):

# Database URL from Postgres bootstrap secret (lab default password is often changeme-stage0)
PG_PASS=$(kubectl get secret postgres-secret -n clearledger \
  -o jsonpath='{.data.password}' | base64 -d)
echo "postgresql://clearledger:${PG_PASS}@postgres:5432/clearledger"
# Use that line for both SEED_AUTH_DATABASE_URL and SEED_LEDGER_DATABASE_URL

# JWT: same value you used at Stage 0, or read from Vault if you already seeded:
kubectl exec -n vault vault-0 -- vault kv get -field=jwt_secret clearledger/auth-service 2>/dev/null \
  || echo "(set SEED_AUTH_JWT_SECRET manually — must match tokens already issued)"

Continue to §5.2 once .env has all four variables set.

5.2: Install Vault and the Agent Injector

set -a && source stages/stage-5-secrets-management/.env && set +a

helm repo add hashicorp https://helm.releases.hashicorp.com && helm repo update

# First install:
helm install vault hashicorp/vault \
  --namespace vault --create-namespace \
  --set server.dev.enabled=true \
  --set server.dev.devRootToken="${VAULT_TOKEN}" \
  --set ui.enabled=true \
  --set injector.enabled=true

# If helm install fails with "cannot re-use a name", use upgrade instead:
# helm upgrade --install vault hashicorp/vault \
#   --namespace vault --create-namespace \
#   --set server.dev.enabled=true \
#   --set server.dev.devRootToken="${VAULT_TOKEN}" \
#   --set ui.enabled=true \
#   --set injector.enabled=true

kubectl wait --for=condition=ready pod \
  -l app.kubernetes.io/name=vault -n vault --timeout=120s
kubectl wait --for=condition=ready pod \
  -l app.kubernetes.io/name=vault-agent-injector -n vault --timeout=120s

kubectl apply -f stages/stage-5-secrets-management/infra/vault-ingress.yaml

Open http://vault.local in your browser. Log in with the value you set as VAULT_TOKEN in stages/stage-5-secrets-management/.env. For example, if your .env has VAULT_TOKEN=my-dev-root-token, use my-dev-root-token as the Vault login token.

Verify: list Vault pods:

kubectl get pods -n vault

Expected: Vault pods:

NAME                                   READY   STATUS    RESTARTS   AGE
vault-0                                1/1     Running   0          1m
vault-agent-injector-8d6b668b4-xxxxx   1/1     Running   0          1m

If helm install fails with “cannot re-use a name”: Vault is already installed. Use the helm upgrade --install block above.

5.3: Configure Vault (Platform + Seed KV)

Run both scripts in order. Each reads VAULT_TOKEN from your .env.

bash stages/stage-5-secrets-management/infra/vault/setup.sh
bash stages/stage-5-secrets-management/infra/vault/seed-vault-secrets.sh

setup.sh: prepares Vault for the cluster: Kubernetes auth, the KV secret store, policies, and roles so auth/ledger pods can fetch secrets later. It doesn't write your database passwords yet and nothing goes to Git.

seed-vault-secrets.sh: takes the SEED_* lines from .env and stores them in Vault at clearledger/data/auth-service and clearledger/data/ledger-service. It doesn't echo those values to the terminal.

Re-running either script is safe for the lab.

Expected, setup.sh (tail):

==> Enabling Kubernetes auth method...
==> Configuring Kubernetes auth...
==> Enabling KV secrets engine...
==> Creating Vault policies...
==> Creating Kubernetes auth roles...
==> Applying RBAC + ServiceAccounts...

✓ Vault platform setup complete (no secrets written yet).
  Next: bash stages/stage-5-secrets-management/infra/vault/seed-vault-secrets.sh

Expected, seed-vault-secrets.sh:

==> Logging into Vault...
==> Writing secrets to Vault KV (values are not printed)...
======== Secret Path ========
clearledger/data/auth-service
======= Metadata =======
Key                Value
---                -----
created_time       2026-06-01T15:31:53.538991153Z
version            1
✓ Secrets stored at clearledger/data/auth-service and clearledger/data/ledger-service

Verify metadata only (no secret values printed):

kubectl exec -n vault vault-0 -- vault kv metadata get clearledger/auth-service

Key                     Value
---                     -----
cas_required            false
created_time            2026-06-01T15:31:53.538991153Z
current_version         1
delete_version_after    0s
max_versions            0
oldest_version          0
updated_time            2026-06-01T15:31:53.538991153Z

5.4: GitOps: Update clearledger-infra (Fixes ArgoCD OutOfSync)

ArgoCD deploys from your clearledger-infra GitHub repo, not from the main clearledger app repo where you're working now. You edit manifests here first, then copy the same changes to clearledger-infra so ArgoCD can sync them. Work slowly and verify after each sub-step.

5.4a. Update manifests in the app repo (clearledger)

cp stages/stage-5-secrets-management/infra/manifests/auth-service/deployment.yaml \
   infra/manifests/auth-service/deployment.yaml

cp stages/stage-5-secrets-management/infra/manifests/ledger-service/deployment.yaml \
   infra/manifests/ledger-service/deployment.yaml\

mkdir -p infra/manifests/vault

cp infra/deferred-by-stage/stage-5-secrets-management/vault/rotation-cronjob.yaml \
   infra/manifests/vault/rotation-cronjob.yaml

rm -f infra/manifests/auth-service/secret.yaml infra/manifests/ledger-service/secret.yaml

5.4b. Edit infra/manifests/kustomization.yaml by hand

Open the file in your editor. In the resources: list:

• Remove the app secret entries: delete these two lines, or comment them out with # (both work, as Kustomize ignores # lines):

  - auth-service/secret.yaml
  - ledger-service/secret.yaml
  

• Add this line (with the other resources):

  - vault/rotation-cronjob.yaml
  

Leave postgres/postgres-secret.yaml, that is Postgres bootstrap only, not app credentials.

Save. Verify:

# Active (uncommented) app secret lines must be gone — postgres-secret is OK
grep -E '^[[:space:]]*-[[:space:]]+(auth-service|ledger-service)/secret\.yaml' \
  infra/manifests/kustomization.yaml && echo "STOP: app secrets still active" || echo "OK"

grep vault/rotation-cronjob.yaml infra/manifests/kustomization.yaml
grep vault.hashicorp infra/manifests/auth-service/deployment.yaml | head -1
kustomize build infra/manifests >/dev/null && echo "OK: kustomize build"

Expected: OK, rotation cronjob listed, first line shows vault.hashicorp.com/agent-inject, kustomize build succeeds.

Commit in the app repo when ready: git add infra/manifests && git commit -m "feat(stage-5): Vault deployments in canonical manifests".

5.4c. Push the same changes to clearledger-infra

git clone https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/clearledger-infra

If clone fails with destination path '/tmp/clearledger-infra' already exists (you cloned in §1.3 or an earlier step), reuse that folder. Don't clone again:

cd /tmp/clearledger-infra && git pull && cd -

Or start fresh: rm -rf /tmp/clearledger-infra then run git clone again.

Run the cp commands from the main clearledger app repo, not from /tmp/clearledger-infra. Your shell prompt should say clearledger, not clearledger-infra. The source path infra/manifests/... only exists in the app repo.

cd ~/clearledger    # main app repo — adjust path if yours differs

cp infra/manifests/auth-service/deployment.yaml /tmp/clearledger-infra/manifests/auth-service/
cp infra/manifests/ledger-service/deployment.yaml /tmp/clearledger-infra/manifests/ledger-service/
mkdir -p /tmp/clearledger-infra/manifests/vault
cp infra/manifests/vault/rotation-cronjob.yaml /tmp/clearledger-infra/manifests/vault/
cp infra/manifests/kustomization.yaml /tmp/clearledger-infra/manifests/kustomization.yaml
rm -f /tmp/clearledger-infra/manifests/auth-service/secret.yaml
rm -f /tmp/clearledger-infra/manifests/ledger-service/secret.yaml

cd /tmp/clearledger-infra
git add -A
git status
git commit -m "feat(stage-5): Vault injection; remove app secrets from GitOps"
git push
cd -

✋ Hands-on checkpoint. Stage 5 GitOps landed

git clone --depth 1 https://github.com/YOUR_USERNAME/clearledger-infra.git /tmp/verify-s5
test ! -f /tmp/verify-s5/manifests/auth-service/secret.yaml && echo "OK: app secret removed from Git"
grep vault.hashicorp /tmp/verify-s5/manifests/auth-service/deployment.yaml | head -1
grep vault/rotation-cronjob.yaml /tmp/verify-s5/manifests/kustomization.yaml
rm -rf /tmp/verify-s5

Expected: OK, Vault annotation present, rotation job in kustomization.

Expected, git status before commit (step 5.4c):

modified:   manifests/auth-service/deployment.yaml
modified:   manifests/ledger-service/deployment.yaml
modified:   manifests/kustomization.yaml
new file:   manifests/vault/rotation-cronjob.yaml
deleted:    manifests/auth-service/secret.yaml
deleted:    manifests/ledger-service/secret.yaml

After git push, ArgoCD will roll out Vault-enabled deployments automatically. Continue to §5.5. Don't expect Synced yet, as app secrets are still in the cluster until you delete them there.

Common rollout failures:

5.5: Wait for Vault-injected Pods, Then Delete K8s App Secrets

Wait until auth/ledger show Vault sidecars (READY 2/2 = app + vault-agent):

kubectl get pods -n clearledger -l app=auth-service
kubectl get pods -n clearledger -l app=ledger-service

Expected:

NAME                            READY   STATUS    RESTARTS   AGE
auth-service-5756d9fcb9-bmdlr   2/2     Running   0          2m
auth-service-5756d9fcb9-jtgss   2/2     Running   0          2m

Inspect sidecar pulled secrets (init container logs):

kubectl logs -n clearledger \
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) \
  -c vault-agent-init
# ... Authentication successful, rendering templates ...

Only after pods are 2/2, delete app Secrets:

kubectl delete secret auth-service-secret ledger-service-secret -n clearledger

Expected: secrets remaining:

kubectl get secret -n clearledger

NAME              TYPE     DATA   AGE
postgres-secret   Opaque   2      6d

postgres-secret is Postgres bootstrap only, not app credentials. That stays until you harden Postgres separately.

If delete says NotFound: secrets were already removed. Continue to §5.6.

5.5b: ArgoCD Should Be Synced After Secret Delete

Run this after §5.5, not right after §5.4. Before you delete app Secrets, OutOfSync is normal. Git no longer lists auth-service-secret / ledger-service-secret, but they still exist in the cluster until you delete them in the step above.

kubectl get application clearledger -n argocd \
  -o jsonpath='sync={.status.sync.status} health={.status.health.status}{"\n"}'

Before secret delete: expect sync=OutOfSync health=Healthy or Progressing while Vault pods roll out. That's fine if auth/ledger are 2/2.

After secret delete, hard-refresh and sync if still OutOfSync:

kubectl annotate application clearledger -n argocd argocd.argoproj.io/refresh=hard --overwrite
argocd app sync clearledger --grpc-web --prune

If sync says another operation is already in progress, wait a minute: ArgoCD auto-sync is already running.

Wait until:

kubectl get application clearledger -n argocd \
  -o jsonpath='{.status.sync.status} {.status.health.status}{"\n"}'
# Synced Healthy

Don't update app deployments with kubectl apply after ArgoCD is managing them. ArgoCD keeps the cluster matched to clearledger-infra. If you change a deployment by hand, ArgoCD may revert it. For Stage 5, update the manifests in Git and let ArgoCD sync the Vault-enabled deployments.

5.6: Login and Injected Files

kubectl exec -n clearledger \
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) \
  -c auth-service -- ls /vault/secrets/

database_url
jwt_secret

curl -s -X POST http://clearledger.local/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@clearledger.io","password":"SecurePass123"}' | jq .

Expected:

{
  "access_token": "<jwt-returned-by-auth-service>",
  "token_type": "bearer"
}

Take a screenshot: working login JSON + kubectl get secret -n clearledger showing no auth-service-secret / ledger-service-secret.

5.7: Health Check

make check-5

What you should see:

make check-5 re-runs Stage 4 checks first, that is expected. Look for the Stage 5 block below to confirm Vault is working.

▶ Stage 4: Admission Control (Kyverno)
  ✓ Kyverno is running
  ✓ Policy disallow-root-containers — Enforce mode
  ...
  ✓ kube-bench matches baseline (no new FAIL regressions)

▶ Stage 5: Secrets Management (Vault)
  ✓ Vault pod is running
  ✓ Vault agent injector is running
  ✓ Vault is unsealed
  ✓ Vault Kubernetes auth method is enabled
  ✓ auth-service-secret removed — Vault is the secret source
  ✓ Vault injected /vault/secrets/database_url into auth-service

All checks passed. Ready for the next stage.

If Vault injection or ArgoCD sync fails, see troubleshooting.md.

Stage 5 is Done: Checklist Before Moving to Stage 6

Stage 5 moves app credentials out of Git and Kubernetes Secrets. It doesn't make Vault production-grade yet. This lab still uses Vault dev mode, not HA or auto-unseal.

Also, a running pod can still read the files under /vault/secrets/ because the app needs those credentials to work. That's normal. Stage 6 adds Falco so you can detect suspicious runtime access.

What You Learned in Stage 5

• Kubernetes Secrets aren't enough for real secret management.

• Vault now stores the app credentials.

• .env was only used locally to load the first secrets into Vault. It's never committed.

• Vault injects secrets into the pod when the app starts.

• clearledger-infra must stop storing secret.yaml, because ArgoCD deploys from that repo.

• The order matters: install Vault, seed secrets, update GitOps, wait for healthy pods, then delete old Kubernetes Secrets.

What you can now say in an interview:

I replaced Kubernetes Secrets with HashiCorp Vault agent injection, removed app credentials from Git and Kubernetes Secrets, and verified the app still worked after Vault injected the credentials at runtime.

Save your progress:

make snapshot STAGE=5 && make snapshots

Confirm clearledger.stage5 appears in the snapshot list.

Stage 6 — Runtime Security (Falco)

Stages 1–5 secured what gets deployed and how secrets are stored. Stage 6 watches what happens inside running containers after they start.

Your goal is to learn what runtime security catches and why it matters, then prove it by triggering a Falco alert and reading it the way an on-call engineer would.

CI, Kyverno, and Vault all act before or at pod startup. Falco fills the gap they leave open. It watches what running software actually does inside the container. That's the layer incident response and forensics care about, not just another chart to install.

Before you start Stage 6:

• make check-5 passes

• Login and transactions still work at http://clearledger.local

• Platform pods have low restart counts

You're done with Stage 6 when:

• You trigger at least one Falco alert

• You apply the network policies

• make check-6 passes

Then save your VM:

make snapshot STAGE=6
make snapshots

Do the Steps in This Order

Each step depends on the one before it. Don't run make check-6 until §6.4. It checks network policies you haven't applied yet.

1. §6.1: bash stages/stage-6-runtime-security/scripts/install-falco.sh. Confirm falco-* pods 2/2 Running and custom rules loaded.

2. §6.2: make demo-6: read ✓ Runtime detection confirmed in the terminal

3. §6.3 (optional) manual break-it scenarios (skip if make demo-6 already worked)

4. §6.4: kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml. Confirm curl http://clearledger.local/ returns 200.

5. §6.6: make check-6

Start at §6.1. If anything fails, see troubleshooting.md.

Optional reading: How Stage 6 fits the full stack: why Falco and netpol exist and how they differ from Stages 3–5.

If You Get Stuck in Stage 6

Stage 6 has three jobs:

1. Install Falco

2. Trigger one test alert

3. Apply network policies

Don't worry about every row in the Falco UI. The UI may show noise. You pass the Falco part when you can find one alert from your demo, either in the terminal or in the UI.

For the portfolio screenshot, open:

http://falco.local

Login:

• Username: admin

• Password: admin

Take a screenshot only after your demo alert appears.

Common stuck points

6.1: Install Falco and Falcosidekick UI

bash stages/stage-6-runtime-security/scripts/install-falco.sh

This runs helm upgrade --install with modern_ebpf, enables Falcosidekick + Web UI, enables the k8s-metacollector (collectors.kubernetes.enabled: true) so custom rules can match k8smeta.ns.name = clearledger, loads rules from infra/falco/clearledger-rules-content.yaml, applies the rules ConfigMap and ingress.

If Falco is already installed, the script is safe to re-run (upgrade).

Verify Falco pods:

kubectl get pods -n falco

Expected output:

NAME                                      READY   STATUS    RESTARTS   AGE
falco-w4fh6                               2/2     Running   0          2m
falco-falcosidekick-...                   1/1     Running   0          2m
falco-falcosidekick-ui-...                1/1     Running   0          2m
falco-falcosidekick-ui-redis-0            1/1     Running   0          2m

The Falco DaemonSet should show 2/2 Running. Sidekick, UI, and Redis pods should each show 1/1 Running. Pod name suffixes on your cluster will differ from the example.

Open http://falco.local. You'll see the Falcosidekick UI. Log in with the chart defaults:

To read the credentials from the cluster instead of trusting the lab defaults:

kubectl get secret falco-falcosidekick-ui -n falco \
  -o jsonpath='{.data.FALCOSIDEKICK_UI_USER}' | base64 -d && echo
# admin:admin

Falcosidekick UI: quick orientation

After login you land on the Events tab. The table can look busy before you run any demo, which is normal.

• Rule: detection name (what fired)

• Priority: Critical / Warning / Notice (focus on Critical and Warning for this lab)

• Output: pod name, file, or command details

• Tags: look for clearledger on lab alerts

Background noise you can ignore: Notice rows from ArgoCD. Critical Sensitive File Read rows from postgres-0 reading /etc/passwd (repeats every few seconds). Your demo alert is different. See §6.2.

Verify custom rules loaded (do this before §6.2):

kubectl get pods -n falco                                    # Falco pod 2/2 Running
kubectl get configmap clearledger-falco-rules -n falco
kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco --tail=200 \
  | grep 'rules.d/clearledger_rules'

Expected: clearledger_rules.yaml | schema validation: ok

An empty grep with --tail=30 alone isn't a failure. Use --tail=200. If you see LOAD_ERR_COMPILE_CONDITION, see troubleshooting.md.

If rules didn't load, §6.2 and §6.3 will look like they passed when nothing fired.

6.2: Guided Demo (make demo-6)

Run this after §6.1 (Falco installed, rules verified, UI opens at http://falco.local).

make demo-6
# or:
bash stages/stage-6-runtime-security/scripts/demo-falco-alerts.sh

What the demo script does

The demo proves Falco can detect suspicious activity inside a running container.

The script checks that Falco is running, opens http://falco.local, and waits while you log in with:

• Username: admin

• Password: admin

Then it runs this test command inside the auth-service container:

kubectl exec -n clearledger \
  auth-service-<pod-suffix> \
  -c auth-service -- /bin/sh -c 'id && exit'

The script picks the real pod name for you.

Non-interactive (CI or no Enter prompts): SKIP_PROMPT=1 make demo-6.

This starts a shell inside the app container. That's suspicious in production because app containers should run the app, not open shells. Falco should detect it and create an alert called:

Shell Spawned in ClearLedger Container

When the script prints:

✓ Runtime detection confirmed

refresh the Falco UI.

Look for a Critical alert with:

• Rule: Shell Spawned in ClearLedger Container

• Pod: auth-service-...

• Command: sh -c id && exit

Ignore alerts from postgres-0, especially Sensitive File Read. Those are background noise for this lab.

If the UI is noisy, search the page for Shell Spawned or check from the terminal:

kubectl logs -n falco -l app.kubernetes.io/name=falco -c falco --tail=500 \
  | grep 'Shell Spawned'

For your screenshot, capture the Shell Spawned alert for auth-service.

6.3: Break-it Scenarios (Manual, Optional)

These are the same detections as §6.2, but you run each command yourself. Skip this section if you already completed make demo-6.

After each command, refresh http://falco.local or use the find methods in §6.2.

Scenario 1 – Shell in a running pod (command injection simulation):

kubectl exec -n clearledger \
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) \
  -c auth-service -- /bin/sh -c "id && exit"

Expected in Falco UI / logs (within ~10 seconds):

CRITICAL: Shell spawned in ClearLedger container
  user=... container=auth-service pod=auth-service-... cmd=sh -c id && exit

What this means: Stage 4 allowed the pod (it is compliant). Stage 6 detected behavior inside the pod: exactly what an attacker would do after command injection.

If you see no alert: confirm the exec used -c auth-service (not the vault-agent sidecar), rules show schema validation: ok, and the pod image name contains clearledger.

Scenario 2 – Read a sensitive file (reconnaissance):

kubectl exec -n clearledger \
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) \
  -c auth-service -- cat /etc/passwd

Expected:

CRITICAL: Sensitive file read in ClearLedger
  file=/etc/passwd container=auth-service pod=auth-service-...

Scenario 3 – Download tool at runtime (optional):

kubectl exec -n clearledger \
  $(kubectl get pod -n clearledger -l app=auth-service -o name | head -1) \
  -c auth-service -- sh -c "wget -q ifconfig.me -O - 2>/dev/null || true"

May fire Package manager executed and/or Unexpected outbound connection (WARNING).

Take screenshots of Scenarios 1 and 2: portfolio evidence for runtime detection.

6.4: Apply Network Policies (Zero-trust Segmentation)

Network policies are firewall rules between pods. Apply them after the Falco demo.

make check-6 checks for these policies, so run it only after this section. The default-deny-all policy blocks traffic by default.

The allow-* policies open only the paths ClearLedger needs to work. Falco detects suspicious behavior. Network policies limit where a pod can connect.

Apply:

kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml
kubectl get networkpolicy -n clearledger

Expected: seven policies: default-deny-all plus six allow-* (auth-service, ledger-service, notification-service, postgres, redis, frontend).

Verify the app still works:

curl -s http://clearledger.local/auth/health | jq .
# {"status":"ok","service":"auth-service"}

curl -s http://clearledger.local/notifications/health | jq .
# {"status":"ok",...}

Checkpoint (required): proves netpol didn't break the real app:

kubectl get networkpolicy -n clearledger
curl -s -o /dev/null -w "%{http_code}\n" http://clearledger.local/
kubectl get pods -n clearledger --field-selector=status.phase!=Running

If auth or ledger start restarting after netpol, egress rules are too strict. See troubleshooting.md.

Scenario 4 – blocked cross-service traffic (optional)

Skip if the checkpoint passed and you plan to run make check-6. This proves ledger can't call notification directly (no allow rule for that path). Failure to connect is success.

Don't use the old wget one-liner: the ledger image has no wget/curl, and head -1 can pick a Terminating pod (exec hangs or exit 137).

LEDGER_POD=$(kubectl get pods -n clearledger -l app=ledger-service --no-headers \
  | awk '$2=="2/2" && $3=="Running" {print $1; exit}')

echo "Using pod: $LEDGER_POD"

kubectl exec -n clearledger "$LEDGER_POD" -c ledger-service -- python3 -c "
import urllib.request
try:
    urllib.request.urlopen('http://notification-service/', timeout=5)
    print('UNEXPECTED: connection succeeded')
except Exception as e:
    print('BLOCKED (expected):', e)
"

Expected:

BLOCKED (expected): <urlopen error timed out>

or Connection refused, not UNEXPECTED: connection succeeded.

6.6: Health Check

Run this after §6.4 (network policies). It confirms Falco, custom rules, and netpol are installed. It does not prove an alert fired (that is §6.2).

make check-6

What you should see:

▶ Stage 6 — Runtime Security (Falco)
  ✓ Falco DaemonSet: 1/1 nodes
  ✓ ClearLedger custom Falco rules ConfigMap exists
  ✓ NetworkPolicy default-deny-all exists
  ✓ NetworkPolicy allow-auth-service exists
  ✓ NetworkPolicy allow-ledger-service exists
  ✓ NetworkPolicy allow-notification-service exists
  ✓ auth-service reachable after network policies
  ✓ notification-service reachable after network policies

All checks passed. Ready for the next stage.

How Stage 6 fits the full stack (optional reading)

Each stage guards a different point in the lifecycle. Stages 1 through 5 work before or during pod startup. Stage 6 watches what happens inside a container that is already running.

• In Stage 3, CI catches bad code and images on git push.

• Stage 4, Kyverno blocks bad pods at admission.

• Stage 5, Vault injects secrets at startup.

• Stage 6, Falco watches syscalls after the pod is running (shell spawns, sensitive file reads).

• Stage 6, Network policies filter pod-to-pod traffic.

They answer three different questions: Kyverno asks whether this pod may be created. Falco asks what the pod is doing right now. Network policies ask who the pod may talk to.

Falco doesn't replace CI or Kyverno. If you skip Stages 3–5, Falco can still alert, but you already shipped vulnerable code and secrets in Git.

Stage 6 is Complete. Proceed to Stage 6.5 or 7.

Portfolio screenshots (optional): shell-in-container alert · sensitive-file read alert in Falco UI.

What comes next: Stage 6 gives you Falco alerts and basic network policies. You can refine the network policies later. Stage 6.5 is optional chaos testing with Litmus, and Stage 7 adds Grafana dashboards so you can see security events over time.

What You Learned in Stage 6

• What runtime security catches that CI and admission control can't: threats inside running containers

• What Falco is: eBPF syscall monitoring with custom YAML rules

• What network policies are: Kubernetes firewall rules between pods

• How to trigger and interpret alerts: incident response skills

• The full stack: code scanning, admission control, secrets management, runtime detection which leads to (next) observability

What you can now put on your CV / say in an interview:

Deployed Falco for runtime threat detection with custom rules, and can trigger and read an alert for a shell-in-container or sensitive-file read the way an on-call engineer would.

make snapshot STAGE=6 && make snapshots. Confirm clearledger.stage6. See How to Save Your Progress.

Stage 6.5 — Chaos Engineering (Optional)

Most learners skip this. If Stage 6 is done and make check-6 passes, jump straight to Stage 7. Nothing in Stages 7–8 requires Litmus.

If you want chaos/resilience (~1 hour): LitmusChaos deletes one auth-service pod and proves /auth/health stays 200 while Kubernetes replaces it.

Do the Steps in This Order

Optional: §6.5.3: same test via make demo-65 (terminal path) instead of the UI wizard.

6.5.0: Before You Start (Auth Pods Must be 2/2)

Chaos deletes pods. If replacements fail to start, you debug CrashLoopBackOff instead of learning resilience.

export GITHUB_OWNER=YOUR_GITHUB_USERNAME   # required — without this, fix-argocd breaks ArgoCD repoURL
make fix-65-prereqs
kubectl get pods -n clearledger -l app=auth-service

Pass: two pods, both 2/2 Ready. Don't install Litmus until this is true.

If something fails:

6.5.1: Install LitmusChaos (Operator, UI, Cluster Connection)

bash stages/stage-6.5-chaos-engineering/scripts/install-litmus.sh
kubectl get pods -n litmus
open http://litmus.local    # login: admin / litmus

Pass before §6.5.2: Overview shows Infrastructures: Active 1 (not 0, not Pending).

Verify pods:

kubectl get pods -n litmus
# litmus-core, chaos frontend/server, mongodb, subscriber — all Running

If Overview shows 0 infrastructures or PENDING

The UI is empty until a subscriber agent connects your cluster:

export LITMUS_PASSWORD='litmus'   # only if you changed the default
bash stages/stage-6.5-chaos-engineering/scripts/connect-litmus-infra.sh

Hard-refresh the browser. Start at http://litmus.local only, not old /account/.../settings bookmarks.

UI navigation (click order for §6.5.2)

1. Overview: Confirm Active 1

2. ChaosHubs, Pod Delete, Launch Experiment

3. Chaos Experiments: watch Running to Completed

Left nav: Overview, Environments, ChaosHub, Chaos Experiments. Skip Resilience Probes and deep Settings URLs for this lab.

6.5.2: Run Your First Experiment (Pod Delete)

Goal: Kill one auth-service pod and prove /auth/health stays 200.

Before you click Run in the UI, open two terminals:

# Terminal A — watch pods
kubectl get pods -n clearledger -l app=auth-service -w

# Terminal B — watch health every 5 seconds
while true; do
  date +%H:%M:%S
  curl -s -o /dev/null -w "health=%{http_code}\n" http://clearledger.local/auth/health
  sleep 5
done

In the UI (http://litmus.local): Left nav → ChaosHubs → Pod Delete card → Launch Experiment.

Litmus UI note: ChaosCenter labels change between versions (for example, “Tune fault”, “Target selection”, “Chaos Experiment”). Match fields by concept, not exact button text. Accept wizard defaults unless the table below lists a value.

In the Litmus UI, open:

ChaosHubs → Pod Delete → Launch Experiment

This opens the experiment wizard. Use these values when the wizard asks for them:

• Infrastructure: clearledger-cluster and it must be Active

• Namespace: clearledger

• Target label: app=auth-service

• Target kind: Deployment

• Pods affected: 50%

• Duration: 30 seconds

• Fault/experiment name: pod-delete

Finish the wizard with Save or Create, then click Run. Don't choose Schedule.

What success looks like:

Prefer terminal over UI? Skip the wizard and run §6.5.3 (make demo-65) instead.

6.5.3 — Same experiment from the terminal (make demo-65) — optional

Use this if you want to run the pod-delete test without clicking through the Litmus UI.

Make sure auth pods are healthy first:

make fix-65-prereqs

Then run the demo:

make demo-65

The script applies the auth-service-pod-delete ChaosEngine in the litmus namespace. Litmus deletes one auth-service pod, Kubernetes replaces it, and the script checks that /auth/health keeps returning 200.

After it finishes, verify the result:

kubectl get chaosresult -n litmus
kubectl get pods -n clearledger -l app=auth-service

You passed if the script ends with PASS, the ChaosResult is Completed / Pass, and two auth-service pods are running again.

You can also see the run in the Litmus UI: Chaos Experiments → refresh → open the latest run.

If new auth pods get stuck in Init:0/1, re-apply the Stage 6 network policies:

kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml

6.5.3a: Real Output Examples (Verified on the Lab Cluster)

These samples were captured from a working cluster after make fix-65-prereqs, make connect-litmus, and make demo-65.

make check-65

▶ Stage 6.5 — Chaos Engineering (LitmusChaos)
  ✓ litmus namespace exists
  ✓ litmus-admin ServiceAccount exists in litmus
  ✓ pod-delete ChaosExperiment installed in litmus
  ✓ Litmus chaos operator is running
  ✓ Litmus ChaosCenter reachable at http://litmus.local
  ✓ Litmus subscriber running (UI connected to cluster)
  ✓ auth-service healthy (baseline before chaos)
  ✓ auth-service has 2/2 Ready replicas (stable for chaos)
  ✓ allow-postgres NetworkPolicy exists (Stage 6 fix)

All checks passed. Ready for the next stage.

make demo-65 captured from a real run (2026-06-01)

Stage 6.5 — auth-service pod-delete

Preflight: 2 auth-service pods Running

Applying ChaosEngine auth-service-pod-delete (namespace litmus)

Watching http://clearledger.local/auth/health

  10s  health=200  pods=2
  20s  health=200  pods=1
  30s  health=200  pods=1
  40s  health=200  pods=2
  50s  health=200  pods=2
  60s  health=200  pods=2

Result:
  ChaosResult: Completed / Pass
  Recovery:    2 auth-service pod(s) Running
  Health:      6/6 checks returned 200

PASS

If health lines show 000, run bash scripts/setup-hosts.sh on your Mac and re-run. The script also tries multipass exec clearledger -- curl when the VM is present.

Terminal B (health loop, expected output)

22:05:01
health=200
22:05:06
health=200
22:05:11
health=200

Pod count may show 1 while the replacement pod is starting, which is expected.

Terminal A during chaos (kubectl get pods -w)

NAME                            READY   STATUS        RESTARTS   AGE
auth-service-84cc988c4d-hdb45   2/2     Running       0          67m
auth-service-84cc988c4d-b59sj   2/2     Terminating   0          15m    ← killed
auth-service-84cc988c4d-dxz9q   0/2     Pending       0          0s     ← replacement
auth-service-84cc988c4d-dxz9q   0/2     Init:0/1      0          2s
auth-service-84cc988c4d-dxz9q   2/2     Running       0          90s

After demo: verify

kubectl get chaosresult -n litmus
# auth-service-pod-delete-pod-delete   Completed   Pass

kubectl get pods -n clearledger -l app=auth-service
# auth-service-84cc988c4d-xxxxx   2/2   Running
# auth-service-84cc988c4d-yyyyy   2/2   Running

kubectl get cm subscriber-config -n litmus -o jsonpath='{.data.IS_INFRA_CONFIRMED}'
# true

Subscriber connected (infrastructure Active in UI)

kubectl logs -n litmus -l app.kubernetes.io/name=subscriber --tail=3
level=info msg="AgentID: a63c2a2c-... has been confirmed"
level=info msg="Server connection established, Listening...."

6.5.4: Understand the YAML Files (Read Before Running)

Each file is a ChaosEngine: a request to Litmus: “run experiment X against app Y for Z seconds.”

litmus-install.yaml

This creates the litmus namespace only. Platform workloads live here, separate from clearledger app pods.

litmus-rbac.yaml

auth-service-pod-delete.yaml (Experiment 1: used by demo)

metadata:
  namespace: litmus          # engine lives here (Kyverno-safe)
spec:
  appinfo:
    appns: clearledger       # target app namespace
    applabel: app=auth-service
    appkind: deployment
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: PODS_AFFECTED_PERC
              value: "50"    # 50% of 2 replicas = 1 pod killed
            - name: TOTAL_CHAOS_DURATION
              value: "30"    # chaos window in seconds

What happens when applied:

1. Operator reads ChaosEngine and creates auth-service-pod-delete-runner pod in litmus

2. Runner selects one auth-service pod in clearledger and sends SIGTERM / delete

3. Kubernetes Deployment controller sees 1/2 replicas and schedules a replacement pod

4. Service routes traffic to the surviving replica during recovery

5. ChaosResult CR records pass/fail from Litmus’s perspective

ledger-service-network-latency.yaml (Experiment 2 — manual)

Adds 2000 ms network latency to ledger-service pods for 60 seconds. Proves timeouts return 503 instead of hanging the UI.

notification-service-memory-hog.yaml (Experiment 3 — manual)

Fills 80% of pod memory limit for 60 seconds. Proves OOMKill + restart behavior.

Never apply all three at once. Run one experiment, verify recovery, then the next.

6.5.5: After the Demo, What to Look For (Do Not Skip)

1. During chaos: availability

2. After chaos: recovery

3. Litmus ChaosResult verdict

kubectl get chaosresult -n litmus

Your pass criteria:

• /auth/health returned 200 at least once during the chaos window

• A pod was Killed (see events)

• Deployment returned to 2 replicas

6.5.6 Manual Experiments (After Experiment 1 Succeeds)

Wait until both auth-service pods show 2/2 Ready, then run one experiment at a time:

# Experiment 2 — 2s network latency on ledger-service (60s)
kubectl delete chaosengine ledger-service-network-latency -n litmus --ignore-not-found
kubectl apply -f stages/stage-6.5-chaos-engineering/infra/chaos/ledger-service-network-latency.yaml

# Experiment 3 — memory pressure on notification-service (60s)
kubectl delete chaosengine notification-service-memory-hog -n litmus --ignore-not-found
kubectl apply -f stages/stage-6.5-chaos-engineering/infra/chaos/notification-service-memory-hog.yaml

Clean up an experiment:

kubectl delete chaosengine auth-service-pod-delete -n litmus

6.5.7: Health Check

make check-65

Expected: see full sample in §6.5.3a (make check-65 block). Minimum:

▶ Stage 6.5 Chaos Engineering (LitmusChaos)
  ✓ Litmus subscriber running (UI connected to cluster)
  ✓ auth-service has 2/2 Ready replicas (stable for chaos)
  ...
All checks passed. Ready for the next stage.

Stage 6.5 Complete: Checklist

What You Learned in Stage 6.5

• Detection ≠ resilience: Falco alerts don't prove HA

• Replicas + Services + probes: why replicas: 2 isn't cosmetic

• ChaosEngine YAML: declarative failure injection as code

• Platform vs app namespaces: Kyverno blocks chaos runners in clearledger, engines run in litmus

• MTTR: time from pod kill to 2/2 Ready again (Stage 7 graphs this)

What you can now put on your CV / say in an interview:

Ran chaos experiments with LitmusChaos (pod-delete, network latency, memory pressure) to prove the system recovers, and can distinguish detection from resilience.

make snapshot STAGE=65 && make snapshots. Confirm clearledger.stage65. See How to Save Your Progress.

Stage 7 — Security Observability

Security you can't measure, you can't prove.

The goal here is to understand how metrics, logs, and dashboards fit together. Then prove it by running commands in the terminal, watching the same events appear in Grafana, and explaining what each panel means.

This stage is not “install Grafana and move on.” Stage 7 isn't complete until your dashboards show real Kyverno violations and Falco alerts that you triggered in §7.4: plus portfolio screenshots (§7.6). make check-7 only proves the stack is up; it does not prove you can detect security events.

Before you start: make check-6 should pass (Stage 6.5 is optional. Skip is fine). Check the VM is not overloaded: multipass exec clearledger -- uptime. If you ran Stage 6.5, do §7.0 first to scale Litmus down. Plan about half a day. This is the heaviest stage on a single-node VM.

You'll be done when §7.6 is complete: dashboards show your Kyverno denial and Falco alert, not empty panels. Then make check-7 (§7.7), make snapshot STAGE=7, and make snapshots (confirm clearledger.stage7).

Already installed? If kubectl get pods -n monitoring shows Grafana 3/3 and Loki 1/1, skip §7.1. Start at §7.2 (verify the stack), then §7.4 (hands-on lab).

What You Need to Know First

Up to now, each stage had its own window into the cluster. Stage 3 gave you CI scan results in GitHub Actions. Stage 4 showed Kyverno blocking a bad deploy in the terminal. Stage 6 gave you Falco alerts in its UI, and you could always run kubectl logs on a pod. Those views are useful, but they are scattered.

Stage 7 brings them together in one place: Grafana. Instead of jumping between five different tools, you open a dashboard and see whether security events, policy violations, and app health are happening over time.

The three tools you're installing

Prometheus collects numbers from the cluster: things like “how many Kyverno denials in the last hour” or “how many HTTP requests per second.” It checks those numbers every 15–30 seconds and keeps a history you can graph.

Loki collects log lines: the same kind of text you see from kubectl logs, but from many pods at once. Falco alerts, failed login attempts, and application errors all land here so you can search them later.

Grafana is the web UI where charts and tables pull data from Prometheus and Loki. This is what you would show an auditor: not a one-off terminal screenshot, but proof that you can find and measure events after they happen.

Prometheus doesn't magically know what to collect. ServiceMonitors and PodMonitors are small config objects that point it at the right targets.
If Kyverno has no monitor, the Kyverno dashboard stays empty even when Kyverno is working fine. The same applies to application request rates. Those panels stay blank until §7.5, when metrics-enabled images are deployed through GitOps.

Logs follow a similar path. Promtail reads container logs and sends them to Loki. If Loki isn't running, Grafana log panels show “No data” even though kubectl logs still works on individual pods.

How this connects to what you already built

When you blocked a bad kubectl apply in Stage 4, Kyverno recorded that denial. In Stage 7, that shows up on the Kyverno Policy Violations dashboard (via Prometheus).

When you triggered a shell inside a pod in Stage 6, Falco wrote an alert. In Stage 7, that appears on the Security Event Timeline (via Loki).

When ClearLedger handles HTTP traffic or a failed login, those events feed the Service Health dashboards (Loki and Prometheus together).

Vault (Stage 5) and network policies (Stage 6) don't always have their own panel, but they still matter: fewer secrets in Git and blocked pod traffic show up indirectly in a healthier, quieter cluster.

What you'll do in this stage

You'll run a command in the terminal (for example, a Kyverno violation or a Falco trigger) and then wait a short time while Prometheus or Loki ingests the event. Within about 15–90 seconds, the matching Grafana panel should update.

That's the whole point of observability for security: the terminal proves the event happened once, while the dashboard proves you can detect and measure it later without being logged into the cluster at that exact moment.

7.0: Free Node Resources (Scale Down Litmus)

Stage 6.5 is complete. You don't need the Litmus UI, MongoDB, or chaos operator running while Prometheus, Loki, and Grafana start. They compete for the same CPUs on a single-node lab VM (6 by default, see scripts/setup-cluster.sh).

Scaling Litmus to zero frees ~500–800MB RAM and reduces CPU churn before the observability install.

kubectl scale deployment,statefulset -n litmus --replicas=0 --all
kubectl get pods -n litmus
# Expected: no Running pods (Succeeded job pods from chaos experiments are OK)
multipass exec clearledger -- uptime
# Expected: load average (1m) ideally below ~8 before continuing

You can scale Litmus back up later if you want to re-run chaos experiments (bash stages/stage-6.5-chaos-engineering/scripts/install-litmus.sh). For Stages 7–7.5, keep it scaled down.

7.1: Install the Observability Stack

This is safe to run more than once. The script checks what's already installed. If Grafana, Prometheus, and Loki are healthy, it skips the heavy install and only updates dashboards and scrape configs. Running it again after a partial failure won't duplicate or break a working stack.

Only add FORCE=1 if something is genuinely stuck, for example you edited the Helm values files and need a full reinstall, or Loki keeps crashing in a restart loop:

FORCE=1 bash stages/stage-7-observability/scripts/install-observability.sh

On a first-time install, use the plain command in Step 1 below. Don't use FORCE=1 unless the troubleshooting section tells you to.

macOS, Linux, and WSL2: FORCE=1 bash ... works as written.

Native Windows PowerShell doesn't use that syntax.

Run the lab inside WSL2 Ubuntu (recommended), or set the variable first: $env:FORCE=1; bash stages/stage-7-observability/scripts/install-observability.sh.

Step 1: install (wait until the script prints ✓ Stage 7 installed.):

bash stages/stage-7-observability/scripts/install-observability.sh

If you see “Waiting for Falco” during the Stage 7 install, that's expected.

You already installed Falco in Stage 6. Stage 7 is not adding a second Falco. It is making sure the existing Falco setup can feed logs and metrics into the observability stack.

The flow is:

• Falco still runs in the falco namespace.

• Promtail sends Falco logs to Loki.

• Grafana reads those logs from Loki.

• The Security Event Timeline dashboard shows the Falco alerts.

Right after install, the Grafana panels may be empty. That's normal. You need to trigger a new alert in §7.4 before the dashboard has something fresh to show.

Step 2. Check pods (run this after Step 1 finishes):

kubectl get pods -n monitoring

You want something like this (pod name suffixes vary):

NAME                                              READY   STATUS    RESTARTS   AGE
kube-prometheus-stack-grafana-....                3/3     Running   0          5m
kube-prometheus-stack-prometheus-....             2/2     Running   0          5m
loki-0                                            1/1     Running   0          5m
loki-promtail-....                                1/1     Running   0          5m

Grafana must show 3/3 Ready (not 2/3). Loki must show 1/1. If pods are still Pending or ContainerCreating, wait a few minutes and run kubectl get pods -n monitoring again.

Expected – Loki healthy:

kubectl exec -n monitoring loki-0 -- wget -qO- http://127.0.0.1:3100/ready

ready

Expected – Grafana can reach Loki (same path log panels use):

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- \
  wget -qO- --timeout=5 http://loki:3100/ready

ready

Expected – Grafana UI reachable:

curl -sI http://grafana.local | head -n 1

HTTP/1.1 302 Found

Log into http://grafana.local: admin / admin123

Empty panels right after install are normal. You haven't generated events yet. Continue to §7.2–§7.4.

If Helm fails: wait 30s, then FORCE=1 bash stages/stage-7-observability/scripts/install-observability.sh. See troubleshooting.md. Stage 7.

✋ Hands-on checkpoint: confirm Loki and dashboards are ready

Before you open Grafana, confirm the logging stack and dashboards actually installed.

On a single-node VM, Grafana can look fine while Loki is crash-looping or the ClearLedger dashboards never loaded. If you skip this check, you may spend the rest of Stage 7 debugging empty panels.

Run:

kubectl get pods -n monitoring
kubectl get pods -n monitoring -l app.kubernetes.io/name=loki \
  -o jsonpath='{.items[*].status.containerStatuses[*].restartCount}{"\n"}'
kubectl get configmap -n monitoring -l clearledger_dashboard=1 --no-headers | wc -l

Expected:

• All monitoring pods are Running

• Grafana shows 3/3 Ready

• Loki shows 1/1 Ready

• Loki restart count is 0, or low and not climbing

• The dashboard count is 6

If Loki keeps restarting or the dashboard count is 0, stop here and fix the install before continuing. Empty Grafana panels usually mean Loki or the dashboards are missing, not that the security events failed.

7.2: Verify Prometheus, Loki, and Grafana (before opening dashboards)

Run these three checks so you know which layer is broken if a panel is empty.

Check 1: Prometheus has Kyverno metrics

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- \
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=kyverno_admission_requests_total' 2>/dev/null \
  | head -c 400

(Prometheus runs as a StatefulSet pod, not a Deployment. This query goes through Grafana to the Prometheus Service.)

Expected: JSON with "status":"success" and a "metric" block (values may be 0 until you trigger a violation in §7.4).

If you see "status":"success" but "result":[], Prometheus is up but Kyverno hasn't recorded admissions yet. That's fine before the lab.

Check 2: Loki has Falco logs

kubectl exec -n monitoring loki-0 -- wget -qO- \
  'http://127.0.0.1:3100/loki/api/v1/labels' 2>/dev/null | head -c 300

Expected: JSON listing labels such as "namespace" (and after Falco events, you'll see "falco" in label values).

Quick log search (may return empty lines until §7.4 Exercise B):

kubectl exec -n monitoring loki-0 -- wget -qO- \
  'http://127.0.0.1:3100/loki/api/v1/query?query=%7Bnamespace%3D%22falco%22%7D&limit=3' 2>/dev/null \
  | head -c 500

Expected: "status":"success". "result":[] means no Falco lines in Loki yet, not a broken Loki.

Check 3: Grafana imported ClearLedger dashboards

curl -s -u admin:admin123 'http://grafana.local/api/search?tag=clearledger' | jq -r '.[].title'

Expected: six titles:

ClearLedger - Compliance Posture
ClearLedger - DORA Metrics
ClearLedger - Kubernetes Audit Log Analysis
ClearLedger - Kyverno Policy Violations
ClearLedger - Security Event Timeline
ClearLedger - Service Health + Auth Security

Or in the UI: go. toDashboards then filter tag clearledger. You should see exactly these six (no missing names).

7.3: Your First 10 Minutes in Grafana

This section is only a tour. You're not proving anything yet.

Rule for all of Stage 7: an empty panel usually means no events have happened in the selected time range, not that Grafana is broken. You create the real events in §7.4.

Step 1: Open Grafana

Go to http://grafana.local and log in:

• Username: admin

• Password: admin123

Step 2: Set the Time Range

In the top-right corner, choose Last 15 minutes.

Keep this setting for all of Stage 7. Wider ranges like Last 24 hours can overload Loki on a single-node lab VM.

Step 3: Open Dashboards One at a Time

Open one dashboard, look around, then move to the next. Don't open all six at once.

1. Kyverno Policy Violations: policy blocks from Stage 4.

2. Security Event Timeline: Falco alerts from Stage 6. You may see old postgres noise in the log table.

3. Service Health + Auth: app traffic and login attempts.

4. Compliance Posture: summary view for auditors. Skim it and come back after §7.4.

5. Audit Log Analysis: empty on MicroK8s by design (audit pipeline not enabled by default).

6. DORA Metrics: deploy-frequency charts. Needs multiple CI runs to accumulate data. May show blank on first look. Optional.

Use the short dashboard links in this guide. Avoid old bookmarked URLs with long random slugs.

You can also find them in Grafana: go to Dashboards then search tag clearledger.

Step 4: How to Read What You See

Grafana panels pull data from two places:

• Prometheus shows numbers over time, like Kyverno violation counts and request rates

• Loki shows log lines, like Falco alerts and auth-service messages

A big number panel asks: did this count go above zero?

A line chart asks: was there a spike after I ran something?

A logs panel shows the actual text, like rule names, CRITICAL, or Failed login attempt.

If only log panels show connection refused, check Loki again in §7.1.

If number panels work but log panels fail, the problem is likely Loki, not Grafana itself.

Step 5: Move On

Open dashboards 1–3, then continue to §7.4.

That's where you'll run commands in the terminal and watch the panels update with real security events.

7.4: Hands-on Lab: Terminal → Dashboard Proof

This is the core learning section. For each exercise: run the command, wait, then confirm in Grafana.

Timing: wait 30–90 seconds after each command for Prometheus scrape and Loki ingestion.

Two Ways to Do This Lab

Option 1: follow the exercises below (recommended for learning)

Run each command yourself, then check Grafana. That's Exercise A, B, and C.

Option 2: use the guided script

The script runs the same steps and pauses so you can check Grafana between them:

bash stages/stage-7-observability/scripts/generate-dashboard-data.sh

Or:

make demo-7

Both commands do the same thing. The script will say things like “Press Enter after you checked the Kyverno dashboard.” Switch to Grafana, look at the panel, then come back and press Enter.

Want it to run without pauses? (faster, less hand-holding)

SKIP_PROMPT=1 make demo-7

Use Option 1 if you want to understand each step. Use Option 2 if you want a walkthrough. Use SKIP_PROMPT=1 if you just want the data generated quickly.

Exercise A: Kyverno block → Prometheus → Kyverno dashboard

Terminal: apply a pod that violates Stage 4 policy (runs as root):

cat <<'YAML' | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: stage7-kyverno-lab
  namespace: clearledger
spec:
  containers:
    - name: test
      image: nginx:alpine
YAML

How to know it worked:

You're testing whether Kyverno blocks a deliberately bad pod. Success means the pod never gets created.

Pass. You should see:

• The terminal prints Error from server and denied the request

• The exact policy names in the error don't matter. Your output might list one rule or several (disallow-root-containers, require-resource-limits, drop-all-capabilities, …). More lines just means more rules failed, that's still a pass.

• The pod name never shows up in the cluster:

kubectl get pods -n clearledger | grep stage7-kyverno-lab

Expected: no output.

If it fails: stop and fix Stage 4 first

• The command ends quietly with created (no error)

• kubectl get pods -n clearledger shows stage7-kyverno-lab

That means Kyverno let a root pod through. Run make check-4 before continuing Stage 7.

Example of a passing terminal (yours may list more policies):

Error from server: error when creating "STDIN": admission webhook "validate.kyverno.svc" denied the request:
policy disallow-root-containers/validate-run-as-non-root fail: Running as root is not allowed

Confirm Prometheus saw it (optional but useful if Grafana is empty):

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- \
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=kyverno_admission_requests_total{request_allowed="false"}' 2>/dev/null \
  | grep -o '"value":\[[^]]*\]' | head -3

Expected: a "value" entry with a recent Unix timestamp and a number greater than 0 (for example "value":[..., "1"]). If you see this, Kyverno and Prometheus are working even when Grafana panels say No data.

Grafana: open Kyverno Policy Violations.

What you're proving: the terminal denial showed up in Grafana. You don't need every panel to light up. You need one clear sign that Kyverno blocks are being counted.

Step 1: quick sanity check (top row, left to right)

1. Policy Violations (time range): big number. Pass: shows 1 or more. Fail: says No data.

2. Violations (time range): same idea, second counter. Pass: 1 or more.

3. Active Kyverno Rules — usually 18. If this number shows up, Grafana can talk to Prometheus. That is good even when the first two panels are still empty.

Step 2: if the top two numbers work, skim the charts

• Violation Rate by Resource Kind (middle chart): look for a bump labeled Pod around the time you ran kubectl apply.

• Top Blocked Resource Types (bottom-left table): look for a Pod row.

• Violations by Namespace (trend) (bottom-right chart): look for a bump for clearledger.

Charts can lag. A big number > 0 in Step 1 is enough to move on. The charts are bonus proof for §7.6 screenshots.

If the top two panels say "No data" but the terminal denial worked:

This is common. Those panels count new denials during the time range, not the total ever recorded. One denial sometimes lands in Prometheus before Grafana's counter moves.

Try this:

1. Run the same kubectl apply command again (denied again, that is expected).

2. Wait 60 seconds.

3. Click Refresh (circular arrow, top-right).

After a second denial you should see 2 in the top stat panels. Screenshot that for §7.6.

Still empty? Use Explore as backup proof:

1. Grafana left menu → Explore

2. Datasource: Prometheus

3. Paste: sum(kyverno_admission_requests_total{request_allowed="false"})

4. Click Run query

Pass: the result is 1 or 2.

A screenshot of the terminal denial plus Explore showing a number > 0 counts as portfolio proof even if the dashboard stats stay slow.

Exercise B: Falco shell → Loki → Security Event Timeline

What you're doing (same idea as Exercise A):

• Exercise A: you did something bad, Kyverno blocked it, and the Grafana Kyverno dashboard updated.

• Exercise B: you do something suspicious inside a running pod, Falco detects it, and Grafana Security Event Timeline updates.

You already did this in Stage 6 (make demo-6). Here you do it again and prove the alert shows up in Grafana, not only in http://falco.local.

The story in one line: pretend you're an attacker who got shell access inside auth-service: Falco should scream, and the scream should appear on the timeline dashboard.

Step 1: trigger the alert (terminal way)

You're pretending an attacker got into auth-service and ran a quick command (id) to see who they're logged in as. That's suspicious. Falco is supposed to catch it.

The block below is three commands in order. Copy-paste the whole block:

AUTH_POD=$(kubectl get pod -n clearledger -l app=auth-service \
  --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}')
echo "Using pod: $AUTH_POD"
kubectl exec -n clearledger "$AUTH_POD" -c auth-service -- /bin/sh -c 'id && exit'

What each line does:

1. Line 1: finds the name of a running auth-service pod and saves it in AUTH_POD.

2. Line 2: prints that name so you can see it worked (not empty).

3. Line 3: runs /bin/sh -c 'id && exit' inside that pod. This is the fake “attack.” Falco watches for shells like this.

Pass: you only need these two lines in the output:

Using pod: auth-service-77b7d9cd99-xxxxx
uid=1000 gid=1000 groups=1000

• First line: a real pod name (not blank).

• Second line: the id command ran inside the container.

That's Step 1 done. The pod is still running. You didn't break anything.

Fail: stop and fix before Step 2:

• error: Internal error or container not found

• Using pod: with nothing after it

Run kubectl get pods -n clearledger -l app=auth-service and retry when one pod shows Running.

Step 2: Confirm Falco saw it (terminal, right away)

The Falco log is one long JSON line. Don't try to read the whole thing. Run:

kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50 | grep -i 'Shell spawned'

Pass. You should see one short phrase somewhere in the line:

Shell spawned in ClearLedger container ... pod=auth-service-... cmd=sh -c id && exit

Or the rule name:

"rule":"Shell Spawned in ClearLedger Container"

That one grep hit means Exercise B worked in the terminal. Screenshot this line for your portfolio.

Ignore:

• Defaulted container "falco" out of: ...: normal kubectl noise

• Lines about postgres-0 and /etc/passwd: background noise from Stage 6, not your test

• The rest of the JSON (output_fields, k8smeta, and so on). You don't need to parse it

If grep prints nothing: run Step 1 again, wait 5 seconds, then re-run the grep.

Step 3: Confirm Loki stored it (wait ~60 seconds first)

The story so far:

• Step 1: you triggered the alert inside auth-service

• Step 2: Falco wrote the alert to its own logs ✓

Step 3 asks: did that log line make it into Loki which is Grafana's log database?

Falco doesn't talk to Grafana directly. Promtail copies Falco's logs into Loki. That copy takes 60–90 seconds. Wait after Step 1, then run this check.

What this command does:

"Search Loki for Falco logs that contain Shell spawned, then show only lines that also mention auth-service."

kubectl exec -n monitoring loki-0 -- wget -qO- \
  'http://127.0.0.1:3100/loki/api/v1/query?query=%7Bnamespace%3D%22falco%22%2Ccontainer%3D%22falco%22%7D%20%7C%3D%20%22Shell%20spawned%22&limit=3' 2>/dev/null \
  | grep -i 'auth-service'

Pass: you see a line with both auth-service and Shell spawned. That means Loki has your alert and Grafana can show it.

Fail (misleading pass): you grep for ClearLedger alone and get a hit from postgres-0 reading /etc/passwd. That's background noise from Stage 6, not your shell test. Always look for auth-service.

Empty output? That's OK. If Step 2 passed, continue to Step 4. Promtail may still be catching up, or the JSON is too long for this quick grep. Grafana often shows the alert even when this command prints nothing.

Step 4: open Grafana

Open Security Event Timeline.

This is the right dashboard. The title at the top should say ClearLedger - Security Event Timeline.

Before you look at panels:

1. Time range: Last 1 hour (top-right)

2. Auto-refresh: Off

3. Re-run Step 1 if your shell command was more than a few minutes ago

4. Wait 90 seconds, then click Refresh

What you'll probably see (and this is normal):

• CRITICAL Alerts (1h): a big number like 1.08 K. That is mostly postgres-0 reading /etc/passwd on a loop (Stage 6 background noise). It does not mean you failed.

• Alerts by Rule Name (pie chart): dominated by Sensitive File Read in ClearLedger. Also normal.

• Recent CRITICAL / WARNING Events: lots of Postgres rows. Your shell alert is in there, but buried.

The top timeline (Falco Alerts by Priority - Timeline) may say No data. That's a known quirk. Don't panic, just use the log panel and browser search instead.

How to find your alert (on this dashboard):

1. Stay on ClearLedger - Security Event Timeline — not Explore, not Tempo.

2. Click inside Recent CRITICAL / WARNING Events (the log list on the right).

3. Press Cmd+F (Mac) or Ctrl+F (Windows/Linux).

4. Search for auth-service or Shell spawned.

If the search finds a row mentioning your pod and Shell spawned, screenshot it.

Wrong place (common mistake): Grafana Explore with datasource Tempo showing ledger-service traces. That's Stage 7.5 (OpenTelemetry), not Exercise B. Tempo shows request traces, not Falco security alerts.

Pass for Exercise B (pick one):

1. Best: Step 2 terminal grep shows Shell spawned and the Security Event Timeline log search finds auth-service / Shell spawned — screenshot both.

2. Also fine: Step 2 grep screenshot plus the Security Event Timeline dashboard with CRITICAL Alerts (1h) showing a number (proves that Falco → Loki → Grafana works, even if your shell row is buried in postgres noise).

3. Fallback (only if the dashboard search fails): Step 2 grep plus Grafana Explore with datasource Loki (not Tempo):

   • Left menu, go to Explore

   • Top-left datasource dropdown: choose Loki

   • Query: {namespace="falco", container="falco"} |= "Shell spawned"

   • Click Run query

   • Look for a line with auth-service

Screenshot for §7.6.

Exercise C: Failed login, Loki, and Service Health

The story: someone is guessing passwords on your login API.
You send ten bad login attempts from the terminal. auth-service writes Failed login attempt to its logs. Grafana Service Health + Auth Security should show the count go up.

Same pattern as A and B: terminal action, then logs, then dashboard.

Step 1: send bad login attempts (terminal)

Copy-paste the whole block:

for i in $(seq 1 10); do
  curl -s http://clearledger.local/auth/health >/dev/null
  curl -s -X POST http://clearledger.local/auth/login \
    -H 'Content-Type: application/json' \
    -d '{"email":"lab-attacker@evil.com","password":"wrong"}' >/dev/null
done
echo "done"

Pass: the only output you need is:

done

No output from the curl lines is normal. The loop hits /auth/health (keeps the app warm) and /auth/login with a wrong password ten times.

Fail: curl: (6) Could not resolve host. Run bash scripts/setup-hosts.sh on your Mac. curl: (7) Failed to connect. Check kubectl get pods -n clearledger -l app=auth-service.

Step 2: Confirm auth-service logged it

kubectl logs -n clearledger -l app=auth-service --tail=30 | grep -i 'Failed login' | tail -3

Pass. You should see lines like:

Failed login attempt for email: lab-attacker@evil.com

You may see several lines (one per failed attempt). One line is enough. Screenshot this for your portfolio.

If grep prints nothing: wait 10 seconds and run again. If still empty, check the auth pod is Running: kubectl get pods -n clearledger -l app=auth-service.

Step 3: open Grafana (wait ~60 seconds after Step 1)

Open Service Health + Auth Security.

This is the right dashboard. The title should say ClearLedger - Service Health + Auth Security.

1. Time range: Last 1 hour

2. Auto-refresh: Off

3. Click Refresh once

What to check (only these matter for Exercise C):

1. Failed Login Attempts (1h): big number. Pass: > 0. This is your main proof.

2. Failed Login Log Stream: log lines in the panel. Pass: lines with Failed login attempt or lab-attacker@evil.com. Use Cmd+F inside the panel if needed.

Panels you can ignore if empty:

• Successful Logins: fine at 0 (you only sent bad passwords)

• Request Rate by Service: may be empty until §7.5 metrics images. Not required for Exercise C.

You pass Exercise C when you have two screenshots:

Screenshot 1 (required): your Step 2 terminal output showing Failed login attempt for lab-attacker@evil.com. This proves the app logged the bad logins.

Screenshot 2 (pick one of these):

• Option A: the Failed Login Attempts (1h) panel showing a number greater than zero (for example 10). This proves Grafana counted the failures.

• Option B: the Failed Login Log Stream panel showing a line with lab-attacker@evil.com. Use this if the big number panel is still empty but the log stream has your email.

You need Screenshot 1 and either Option A or Option B. That's enough for §7.6.

Exercise D: Compliance dashboard (the auditor summary)

What you're doing: open one dashboard that rolls up Exercises A, B, and C. This is the “show the auditor” view: admission control + runtime detection + application security in one screen.

When: only after you finished A, B, and C.

Step 1: open the dashboard

Compliance Posture

Set Last 1 hour, auto-refresh Off, click Refresh.

Step 2: Check the top row stats

All three don't need to be huge numbers. They just need to be above zero after your tests.

If one stat is still 0: re-run that exercise (A, B, or C), wait 90 seconds, refresh. Policy Violations may need a second Kyverno denial like Exercise A.

This is screenshot #3 for §7.6: the single frame that proves defense-in-depth.

✋ Hands-on checkpoint: are you actually done with Stage 7?

Installing Grafana isn't the goal. Detection is: you triggered real events and can see them on dashboards.

Optional terminal check (proves Grafana is wired up):

curl -s -u admin:admin123 'http://grafana.local/api/search?tag=clearledger' | jq -r '.[].title'

curl -s -u admin:admin123 'http://grafana.local/api/datasources' | jq -r '.[].name'

First command, you should see six dashboard names:

• ClearLedger - Kyverno Policy Violations

• ClearLedger - Security Event Timeline

• ClearLedger - Service Health + Auth Security

• ClearLedger - Compliance Posture

• ClearLedger - Kubernetes Audit Log Analysis

• ClearLedger - DORA Metrics

Second command, you should see at least:

• Prometheus

• Loki

What does NOT mean you're done:

make check-7 only checks that monitoring pods are running. Green output there does not replace §7.4.

What DOES mean you are done:

You ran Exercises A, B, and C in §7.4 and saved the §7.6 screenshots:

1. Kyverno denial (terminal + dashboard)

2. Falco shell alert (terminal + Security Event Timeline)

3. Failed logins (terminal + Service Health)

4. Compliance Posture summary (all three stats above zero)

If you have those four screenshots, Stage 7 is complete.

7.5: Fill in the Request Rate Chart (Optional)

This is not required for Stage 7. Exercises A–C and §7.6 screenshots don't need this section. Skip it if you're happy moving on.

Also, this is not the same as Stage 7.5 (OpenTelemetry/Tempo). This subsection is only about the Request Rate by Service chart on the Service Health dashboard.

What this section is for:

On Service Health + Auth Security, the Failed Login panels work from logs (Loki). The Request Rate by Service chart needs something different: app pods must expose a /metrics endpoint so Prometheus can scrape request counts.

The code is already in the repo (app/*/prom_metrics.py). Prometheus is already configured to scrape it (clearledger-podmonitor.yaml). The usual problem: your cluster is still running older images from before that code was in your build.

Step 1: check if you already have metrics (30 seconds)

Run this first. If it passes, skip the rest of §7.5.

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- \
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=http_requests_total' 2>/dev/null \
  | grep -o '"__name__":"http_requests_total"' | head -1

Pass: prints "__name__":"http_requests_total". Open Service Health, refresh, and the Request Rate by Service chart should already have lines.

No output: continue to Step 2.

Step 2: deploy images that expose /metrics

Pick one path.

Path A: GitOps (if you have been using CI/CD since Stage 1–2)

1. Push a commit to main on your app repo.

2. Wait for CI to build new images and update clearledger-infra.

3. Wait for ArgoCD to show Synced and Healthy on the clearledger app.

4. Go to Step 3.

Path B: lab shortcut (faster, local only)

export DOCKER_USERNAME=your-dockerhub-user
bash stages/stage-7-observability/scripts/build-metrics-images.sh

This builds, pushes, and rolls out metrics-enabled images for all three services.

Heads-up: ArgoCD self-heal may revert these image tags within a few minutes if clearledger-infra still points at older tags. That's fine for a quick lab demo. For a lasting fix, use Path A or update the infra repo (see §2 rollback notes).

Step 3: verify metrics landed (~60 seconds after rollout)

kubectl exec -n clearledger deploy/auth-service -c auth-service -- \
  wget -qO- http://127.0.0.1:8000/metrics 2>/dev/null | head -5

Pass: lines starting with # HELP or http_requests_total.

Then confirm Prometheus sees them:

kubectl exec -n monitoring deploy/kube-prometheus-stack-grafana -c grafana -- \
  wget -qO- 'http://kube-prometheus-stack-prometheus.monitoring:9090/api/v1/query?query=http_requests_total' 2>/dev/null \
  | grep -o '"__name__":"http_requests_total"' | head -1

Pass: "__name__":"http_requests_total"

Generate a little traffic (re-run the Exercise C curl loop or hit http://clearledger.local/auth/health a few times), wait 60 seconds, then open Service Health + Auth Security and refresh. Request Rate by Service should show lines for auth-service, ledger-service, or notification-service.

When to stop:

• Request Rate still empty but Failed Login panels work? You're done with Stage 7. Request Rate is a nice-to-have.

• Prometheus query passes but chart empty? Widen time range to Last 1 hour, generate traffic, wait 60s, refresh.

7.6: Wrap up Stage 7 (Screenshots + Done Check)

You're almost done. This section is just about saving proof, then moving on.

Are you actually finished?

Opening Grafana and seeing six dashboards isn't enough. make check-7 passing isn't enough either. That only proves pods are running.

You're done when you ran §7.4, waited for the panels to update, and saved three screenshots from your cluster.

If the panels are empty or only show old Postgres noise, go back to §7.4 first.

Before each screenshot: set time range to Last 15 minutes (or Last 1 hour for Exercise B). Include the time picker and panel titles in the frame.

Screenshot 1: Falco alert (Exercise B)

Open Security Event Timeline.

Capture Recent CRITICAL / WARNING Events with a row that mentions Shell spawned or auth-service. If postgres rows bury it, use Cmd+F inside the log panel, that still counts.

Screenshot 2: Kyverno denial (Exercise A)

Open Kyverno Policy Violations.

Capture Policy Violations (time range) or Violations (time range) showing a number of 1 or more.

Screenshot 3: Compliance summary (Exercise D)

Open Compliance Posture.

Capture the top row with all three stats above zero: Policy Violations, Runtime Threats, and Failed Auth Attempts.

Screenshot 4 (optional): Failed logins (Exercise C)

Open Service Health + Auth Security.

Capture Failed Login Attempts (1h) above zero, or Failed Login Log Stream showing lab-attacker@evil.com.

Save files somewhere sensible, like docs/evidence/stage-7-screenshot-1-falco.png. Name them so you know what each proves.

Final check: run make check-7 (§7.7), save your VM, and you can claim Stage 7.

7.7: Verify

make check-7

Expected:

▶ Stage 7 — Observability (Grafana + Prometheus + Loki)
  ✓ Prometheus is running
  ✓ Grafana reachable (http://grafana.local or in-cluster health OK)
  ✓ Loki pod is running (0 restarts)
  ✓ Loki reachable from Grafana (http://loki:3100/ready)
  ✓ ClearLedger alerting rules exist
  ✓ ClearLedger dashboards imported (6 found)

Warnings about Loki restarts or missing dashboards: fix with §7.1 before claiming Stage 7 complete.

Save your VM after §7.6 and make check-7. See the block at the end of Stage 7 below.

7.8: What Broke (Lab Notes + Interview Talking Points)

The stack in one sentence: Prometheus stores numbers (metrics), Loki stores log lines, and Grafana displays both visually. Nothing appears until something actually happens in the cluster.

What tripped you up in the lab

1. Empty dashboards right after install: Normal. Grafana doesn't create events. You trigger them in §7.4 (Kyverno denial, Falco shell, failed logins).

2. Loki slow or refresh stuck on “Cancel”: Falco logs are huge. Last 24 hours overloads a small cluster. Use Last 1 hour, one dashboard at a time, and wait ~10 seconds.

3. make check-7 passed but panels still empty (lab checklist only, not an interview topic): The health check confirms Prometheus/Loki/Grafana pods are up. It does not mean events exist. You still need §7.4 + §7.6 before you snapshot and move on.

If someone asks about this in an interview

Empty dashboards? Grafana only shows what already happened. No event in the time range means an empty panel. That's normal until you trigger something.

Loki slow on a small cluster? Falco logs are huge. We kept time ranges short (15 minutes, not 24 hours) and opened one dashboard at a time. Same trade-off you would make in prod on limited hardware.

How did you prove it worked? I ran the attacks myself: denied a bad pod, spawned a shell in a running container, and sent failed logins. Then I checked Grafana and screenshot the matching panels. Terminal action first, dashboard proof second.

Short version you can say out loud:

"I connected Kyverno and Falco into Grafana. To prove it, I triggered a policy block and a runtime alert, then showed both on security dashboards. On a single-node lab, Loki got slow with wide time ranges, so we kept queries tight."

Pipeline problems from earlier stages (Trivy, Kyverno, image tags, and so on) are in docs/troubleshooting.md — not something you need to rehearse for Stage 7.

7.9: If Panels Look Wrong After a Repo Update

Re-apply dashboards, then generate real events (§7.4, not fake data):

bash stages/stage-7-observability/scripts/install-observability.sh
# Then run Exercises A–C from §7.4 (Kyverno denial, Falco shell, failed logins)

Open Grafana at Last 1 hour, wait ~30–60s after each exercise, and refresh once. The §7.4 exercises cover expected appearance for each dashboard.

What You Learned in Stage 7

• Prometheus proves countable security events (Kyverno denials, HTTP rates)

• Loki proves forensic detail (Falco JSON, auth log lines)

• Grafana is the narrative layer, not a second install step after the lab

• You can trace: terminal action, backend signal, panel update

• ServiceMonitors / PodMonitors are what connect Stages 4–6 to charts

• Empty dashboards mean “no events yet” or “wrong time range”, not “broken security”

• Compliance posture is how you answer an auditor in one screen

• Network policies must explicitly allow the monitoring namespace to reach app pods on port 8000, otherwise PodMonitor scrapes silently fail with context deadline exceeded

• Kubernetes Audit Log dashboard is empty on MicroK8s by design: the API server audit pipeline (audit-policy → file → Promtail → Loki) isn't enabled by default

• Request Rate requires the full chain: app image with /metrics, PodMonitor, and network policy: any one missing means the panel stays empty

What you can now put on your CV / say in an interview:

Built security observability with Prometheus, Loki, and Grafana (dashboards correlating Kyverno violations, Falco alerts, and DORA metrics) and can prove a security event end-to-end from terminal to dashboard.

Stage 7 done checklist:

• make check-7 → 6/6 ✓ (Stage 6.5 Litmus failure is expected: scaled down for memory)

• http://grafana.local/d/clearledger-kyverno-violations. Violations stat > 0

• http://grafana.local/d/clearledger-security-events. CRITICAL Falco alert visible

• http://grafana.local/d/clearledger-compliance. Policy Violations + Runtime Threats + Failed Auth Attempts all > 0

• http://grafana.local/d/clearledger-service-health. Failed Login Attempts > 0. Request Rate > 0 only if you did §7.5

• Portfolio screenshots 1–3 saved

make snapshot STAGE=7 && make snapshots. Confirm clearledger.stage7. Don't skip this. Stage 7 is heavy, and disk pressure is common. See How to Save Your Progress.

After a Mac reboot or sleep, auth/ledger pods may show Unknown or Init:0/1 even though the cluster is up (see troubleshooting.md) Mac reboot).

Stage 7.5 — OpenTelemetry (Optional)

You can skip this whole stage. Stage 7 (metrics + logs) is enough to finish the homelab and move to Stage 8.

Only do Stage 7.5 if you want distributed traces for your portfolio or interviews, and your VM has spare RAM (about 1.5 Gi free).

What You Are Adding

Stage 7 answers: did something happen? (Kyverno blocked a pod, Falco saw a shell, or login failed.)

Traces answer: what steps ran on this one request, and how long did each take?

• Metrics: how many requests, how many errors

• Logs: what the app printed in its log file, such as errors, warnings, login failures)

• Traces: ledger-service called auth-service (12ms), then Postgres (8ms)

In this stage, you send one real transaction, then open that request in Grafana Explore (Tempo). You'll see each step listed with its timing: ledger-service, auth-service, Postgres.

Before You Start

1. Finish Stage 7: §7.4 exercises done, §7.6 screenshots saved, SKIP_CHAOS_CHECK=1 make check-7 passes.

2. Check VM memory: multipass exec clearledger -- free -h , want about 1.5 Gi free.

3. If you ran Stage 6.5 Litmus, scale it down first (§7.0).

You're done when you see the full request trace in Grafana Explore (Tempo datasource) and make check-75 passes. Then make snapshot STAGE=75.

Ignore This Warning in App Logs

Since Stage 7 you may see:

WARNING: Transient error StatusCode.UNAVAILABLE encountered while exporting traces

That is harmless. The apps are already set up to send trace data, but the receiver isn't installed until §7.5.3.

Your apps still work fine, the trace data just gets thrown away. Installing the collector in §7.5.3 makes the warning go away.

How Tracing is Wired

1. Your apps send trace data when a request runs

2. OTel Collector receives it (port 4317) and passes it along

3. Grafana Tempo stores it

4. Grafana Explore (Tempo selected) is where you look at one request step by step

Apps talk to the collector only, not to Tempo directly. That way you can change where traces are stored later without rebuilding the apps.

7.5.1: Check Memory and Load

Tempo needs ~300MB. Confirm headroom before installing:

multipass exec clearledger -- free -h    # want ~1.5Gi available
multipass exec clearledger -- uptime      # load should be reasonable for your CPU count
SKIP_CHAOS_CHECK=1 bash scripts/health-check.sh 7

If Litmus is still running from Stage 6.5, scale it down first (§7.0):

kubectl get pods -n litmus --field-selector=status.phase=Running
# Expected: no resources found

7.5.2: Install Grafana Tempo

Tempo is the trace storage backend. Install it into the monitoring namespace next to Prometheus and Loki:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm install tempo grafana/tempo \
  --namespace monitoring \
  --set tempo.storage.trace.backend=local \
  --set tempo.storage.trace.local.path=/var/tempo \
  --set persistence.enabled=true \
  --set persistence.size=5Gi \
  --wait

Verify Tempo is running:

kubectl get pods -n monitoring -l app.kubernetes.io/name=tempo
# Expected: tempo-0   1/1   Running

kubectl exec -n monitoring tempo-0 -- wget -qO- http://localhost:3200/ready
# Expected: ready

7.5.3: Deploy OTel Collector and Wire Grafana

This applies the OTel Collector (receives spans from app pods) and registers Tempo as a Grafana datasource automatically via the sidecar:

kubectl apply -f stages/stage-7.5-opentelemetry/infra/otel/otel-collector.yaml
kubectl apply -f stages/stage-7.5-opentelemetry/infra/otel/grafana-datasource-tempo.yaml

Verify the collector is running:

kubectl get pods -n monitoring -l app=otel-collector
# Expected: otel-collector-xxxxx   1/1   Running

Verify the collector started (not trace receipt yet):

Apps push spans to the collector over OTLP: the collector doesn't scrape pods. At this step you're only confirming that it's listening.

kubectl logs -n monitoring deploy/otel-collector --tail=15
# Expected:
#   Starting GRPC server ... endpoint: 0.0.0.0:4317
#   Starting HTTP server ... endpoint: 0.0.0.0:4318
#   Everything is ready. Begin running and processing data.
# No crash loops or repeated errors.

Proof that traces are actually flowing comes later: after you generate traffic in §7.5.6, check collector logs for span export lines from the debug exporter, then confirm the trace in Grafana Tempo (§7.5.7).

7.5.4: Enable Prometheus Remote Write Receiver

The OTel Collector also forwards OTel metrics to Prometheus via remote write. Prometheus needs to accept them:

helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  -f stages/stage-7-observability/infra/helm/kube-prometheus-stack-values.yaml \
  --wait

This applies the enableRemoteWriteReceiver: true setting added to the Helm values in Stage 7.5. Wait for Prometheus to restart (about 60 seconds).

7.5.5: Verify App Pods Connect to the Collector

The deployments in clearledger-infra already have OTEL_EXPORTER_OTLP_ENDPOINT set. Once the collector is running, the pods auto-connect.

Confirm that the OTEL warnings are gone:

kubectl logs -n clearledger deploy/ledger-service -c ledger-service --tail=20 2>/dev/null \
  | grep -v "opentelemetry\|otlp\|Transient" | tail -10
# Expected: only INFO request logs, no WARNING: Transient error

If warnings persist, the network policy may not have port 4317 egress. Apply the latest policies:

kubectl apply -f infra/deferred-by-stage/stage-6-runtime-security/netpol/network-policies.yaml

7.5.6: Generate a Trace

Now create a transaction and watch it flow through the system:

# Step 1: register (skip if already registered)
curl -s -X POST http://clearledger.local/auth/register \
  -H "Content-Type: application/json" \
  -d '{"email":"trace-demo@clearledger.io","password":"TracePass123"}' | python3 -m json.tool

# Step 2: login and grab the token
TOKEN=$(curl -s -X POST http://clearledger.local/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"trace-demo@clearledger.io","password":"TracePass123"}' \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
echo "Token acquired: ${TOKEN:0:20}..."

# Step 3: create a transaction (this is the request you will trace)
curl -s -X POST http://clearledger.local/ledger/transactions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"amount": 5000, "direction": "credit"}' | python3 -m json.tool

Verify the collector received spans:

kubectl logs -n monitoring deploy/otel-collector --tail=30 \
  | grep -iE "Traces|spans|ResourceSpans" || echo "No span lines yet — see §7.5.5 (OTEL env / netpol)"
# Expected after a successful transaction: debug exporter lines mentioning exported traces/spans

7.5.7: View the Trace in Grafana

Open http://grafana.local and go to the left sidebar Explore (compass icon).

Step 1: Select Tempo and open Search

At the top of the query pane:

1. Datasource dropdown (orange T logo) → Tempo

2. Query row labeled A (Tempo) → three tabs: Search | TraceQL | Service Graph

3. Click Search. This shows dropdown filters. TraceQL is a text box only. If you land there with nothing typed you get 0 series returned.

Step 2: Filter by service

In the Search tab:

• Service Name → type or select ledger-service

• Leave Span Name, Status, Duration, and Tags empty for now

• Grafana shows the query it will run: {resource.service.name="ledger-service"}

Set the time range (top-right clock icon) to Last 15 minutes so your §7.5.6 transaction is included.

Step 3: Run the query

Grafana Explore has no “Run query” button: results appear automatically after selecting a service. If the table stays empty, use the blue refresh button top-right of the pane.

Step 4: Open the trace waterfall

Below the query editor, find Table - Traces. You should see at least one row like:

Click the Trace ID link. The right panel opens the trace detail view.

What the trace detail view shows

Header: ledger-service: POST /transactions

• Trace ID: unique ID for this request

• Duration: total end-to-end time

• Services: 2 (ledger-service and auth-service for a normal transaction)

Expand spans in the timeline:

ledger-service   POST /transactions          (~total duration)
  ├── auth-service   GET /verify             ← JWT check over HTTP
  ├── ledger-service INSERT / sqlalchemy    ← Postgres write
  └── (optional) redis PUBLISH              ← only if amount ≥ notification threshold

Reading the trace detail screen:

Each row is one step in the request (Grafana calls it a span). The colored bar on the right shows how long that step took. That's the span bar. A longer bar = more time spent on that step.

Click a row or its bar to open the details panel on the right. You'll see two kinds of metadata:

• Span attributes: what happened in this step.
  Examples: HTTP method (POST, GET), status code (200), or SQL text on a database step. In your trace you might see asgi.event.type: http.request on the FastAPI receive step.

• Resource attributes: where the step ran.
  Examples: service.name: ledger-service, k8s.cluster.name: clearledger, deployment.environment: production.

Quick mental model: span attributes = what the step did. Resource attributes = which service produced it.

Connecting traces to logs: once you have a step selected, the Logs tab will take you straight to the matching Loki log lines for that pod at the same moment in time.

Screenshot this trace detail view: portfolio proof for Stage 7.5.

TraceQL alternative

If you prefer the text box, Switch to the TraceQL tab, and paste:

{ resource.service.name = "ledger-service" }

If the table is empty

If TraceQL says 0 series returned: Use the Search tab instead, or paste the TraceQL query from above into the TraceQL tab.

If search tab has no rows: Widen the time range to Last 15 minutes, re-run the transaction curl from §7.5.6, wait a few seconds, and refresh.

If grafana can't connect to Tempo: The datasource URL needs port 3200. Re-apply the datasource and restart Grafana:

kubectl apply -f stages/stage-7.5-opentelemetry/infra/otel/grafana-datasource-tempo.yaml
kubectl rollout restart deployment/kube-prometheus-stack-grafana -n monitoring

If collector logs show no trace data: Work through §7.5.5: usually the OTEL environment variables or network policy blocking port 4317.

7.5.7b: Understand When a Trace Happens

You ran one curl command in §7.5.6. Grafana shows every place that single request traveled.

Think of it like tracking a package:

1. You sent POST /transactions to ledger-service

2. ledger-service asked auth-service: "is this user logged in?"

3. ledger-service saved the row to the database

4. redis only runs if the amount is big (10,000 or more)

Each of those is a row you see in the Tempo detail screen. You're not looking at four separate requests. It's one request with multiple stops.

Why do I see both ledger-service and auth-service?

Because ledger had to call auth before it could save the transaction. Grafana groups those stops into one trip so you can see the full path, not just the first hop.

Why did my demo have no Redis row?

You used "amount": 5000. The app only talks to Redis when the amount is 10,000 or higher. So seeing ledger + auth + database but no Redis is correct.

Want to see Redis? Run §7.5.6 again with "amount": 15000 and search Tempo again.

Optional: connect it to the code

Open app/ledger-service/main.py, find create_transaction, and read top to bottom. The Tempo rows follow that function in order: check the user, save to the database, and maybe notify Redis.

Optional: same request, three tools

At the time you ran the curl:

• Tempo (this stage): which services ran and how long each took

• Loki (Stage 7): what the apps wrote in their log files

• Prometheus (Stage 7): how many requests happened around that time

Same moment, three different views. You already used Loki and Prometheus in Stage 7.

7.5.8: Verify

make check-75

Expected output:

▶ Stage 7.5 — OpenTelemetry (Distributed Tracing)
  ✓ OTel Collector is running (1 replica(s))
  ✓ Grafana Tempo datasource ConfigMap exists
  ✓ Tempo is running
  ✓ auth-service has OTEL_EXPORTER_OTLP_ENDPOINT set

If you see a warning instead:

⚠ OTel env vars not found on auth-service, redeploy with updated manifests

check-75 looks for OTEL_EXPORTER_OTLP_ENDPOINT in the deployment manifest. Older Stage 5 manifests may not list it even though tracing works: the Python apps default to http://otel-collector.monitoring.svc.cluster.local:4317 when the env var is missing.

You can proceed if collector logs show spans and Tempo shows your trace. To clear the warning, apply only the app deployments (not the whole kustomize tree: Kyverno may block redis/postgres patches):

kubectl apply -f infra/manifests/auth-service/deployment.yaml
kubectl apply -f infra/manifests/ledger-service/deployment.yaml
kubectl rollout restart deployment/auth-service deployment/ledger-service -n clearledger
make check-75

Save your VM after make check-75. See the block at the end of Stage 7.5 below.

What You Learned

Stage 7 gave you metrics (how busy?) and logs (what was printed?). Stage 7.5 adds traces (for one slow request, which step took the time?).

In the lab you proved it with one POST /transactions curl. In production the idea is the same: a user hits an API, the request crosses multiple services, and you need to see that full path in one place.

If someone asks in an interview:

Why traces at all? Metrics might tell you p99 latency doubled. Logs might show an error on one pod. Traces tell you which downstream call in the chain caused the delay, auth, database, cache, or third-party API, without guessing.

How did you implement it? We instrumented the services with OpenTelemetry, sent telemetry to a collector, and stored traces in Grafana Tempo. Apps talk to the collector, not directly to the backend, so we can change storage later without redeploying every service.

What would you do in an incident? Find a slow or failing trace ID (from logs, metrics, or an alert), open it in Tempo, walk the call chain service by service, see where time stacked up, then jump to logs for that service at the same timestamp. That's faster than tailing logs on five pods and hoping they line up.

Short version you can say out loud:

"We use the three pillars together: Prometheus for rates and errors, Loki for log detail, and Tempo for request-level debugging across microservices. When latency spikes, I start from a trace, identify the slow hop, often a database or downstream API, and correlate back to logs and metrics for that service."

make check-75 && make snapshot STAGE=75 && make snapshots. Confirm clearledger.stage75. See How to Save Your Progress.

Stage 8 — AWS Migration

Your goal here is to run the same ClearLedger app on AWS instead of your laptop VM.

You're not rewriting the application. Stages 0–7 built containers on Kubernetes with GitOps, Kyverno, secrets, and observability. Stage 8 changes where it runs. You keep the same images, the same ArgoCD workflow, and the same security policies. Only the cloud services underneath change (MicroK8s → EKS, Vault → Secrets Manager, and so on).

• Homelab: MicroK8s, Postgres in a pod, dev Vault, Docker Hub, clearledger.local

• AWS: EKS, RDS, Secrets Manager, ECR, ALB hostname

Am I ready for Stage 8?

• Homelab complete through Stage 7 (Stage 7.5 optional)

• make check-7 passes (and make check-75 if you did traces)

• AWS account with billing alerts enabled. make aws-up creates billable resources

• Skim §8.2 so you know what make aws-up does (even if you use the quick path)

Done when the app is reachable on the AWS ALB, ArgoCD syncing, and you run make aws-down when finished to stop charges.

What make aws-up Gives You

This is a demo stack: production-shaped, but not production-ready. It has HTTP only (no TLS cert).

Stage 7 observability is installed automatically. CI still runs Gitleaks, Semgrep, Checkov, Trivy, and Cosign.

For real production, you would add HTTPS (see ingress-aws-https.example.yaml), staging before promote, and alert routing. Those are documented but not applied by the spinup script.

GitOps rule: after bootstrap, don't kubectl apply app Deployments by hand. ArgoCD owns the cluster (Stage 2). Push manifest changes to Git and let ArgoCD sync.

Secrets on AWS

On the homelab, Vault wrote secret files into the pod. On AWS, secrets live in AWS Secrets Manager (created by Terraform). Your app still needs them as environment variables like DATABASE_URL.

ESO (default in this lab): the simple mental model:

1. Terraform stores the real password in AWS Secrets Manager (for example clearledger/auth-service)

2. External Secrets Operator (ESO) watches that AWS secret

3. ESO copies it into a normal Kubernetes Secret inside the cluster (for example auth-service-secret)

4. Your deployment reads DATABASE_URL from that Kubernetes Secret, same as Stage 0, but the values come from AWS instead of a YAML file in Git

You never put passwords in Git. ESO keeps the Kubernetes Secret in sync with Secrets Manager.

CSI (optional, §8.5 exercise): same AWS secrets but different delivery: mounted as files at /mnt/secrets/* instead of env vars. This is closer to how Vault worked on the homelab.

IRSA: how ESO is allowed to read Secrets Manager without storing AWS access keys in the cluster. AWS trusts a Kubernetes service account instead.

IRSA lets AWS trust a Kubernetes ServiceAccount, no AWS_ACCESS_KEY_ID in Git or in the cluster.

Details here: stages/stage-8-aws-migration/docs/secrets-patterns.md.

8.1: Two Ways Through Stage 8

Quick path (~45–60 min): edit terraform/secrets.tf (replace CHANGE_ME_BEFORE_APPLY), then:

make aws-up    # runs stages/stage-8-aws-migration/scripts/aws-spinup.sh
make aws-down  # destroys billable resources when you are done

Read §8.2 afterward so you know what ran.

Manual path (§8.3): run Terraform, ECR push, ArgoCD, Kyverno, ESO, and deploy yourself. Use this when learning, interviewing, or debugging a failed spinup.

Don't skip §8.2–§8.5 if you only ran make aws-up. Otherwise you won't know what Terraform, ESO, or ArgoCD each did.

Before your first Stage 8 push, read §8: CI routing and CLEARLEDGER_CI_TARGET and set CLEARLEDGER_CI_TARGET=aws only after Terraform succeeds, not while you are still on Stages 1–7.

8.2: What make aws-up Runs

The spinup script runs 15 steps in order:

Setup (1–6): Check tools and AWS login; terraform apply (VPC, EKS, RDS, ECR, Secrets Manager, GuardDuty, CloudTrail, IAM), confirm security services, build and push images to ECR, patch manifests/kustomization.yaml with your registry and git SHA, and configure kubectl for EKS.

Platform (7–12): install ArgoCD; Kyverno + cluster policies, Falco, External Secrets Operator + IRSA service accounts, CSI secrets driver, and Stage 7 observability stack.

Deploy (13–15): ArgoCD app clearledger-aws syncs stages/stage-8-aws-migration/manifests/, wait for ALB hostname, and print URL and tear-down reminder.

After the script finishes, open the printed http://<alb-dns>/ in your browser (ClearLedger login UI), or follow §8.3. When to open what for Argo CD and Grafana port-forwards.

Default app deploy uses ESO for secrets. CSI is also installed so you can try file mounts in §8.5 without extra setup.

Terraform layout: there's no terraform.tf file. The terraform {} block (version, providers, optional S3 backend) is at the top of main.tf. Resources are split by topic: vpc.tf, eks.tf, rds.tf, ecr.tf, alb.tf, iam.tf, secrets.tf, security.tf.