Forem: Steven Hoang

[Tools] Drunk Charts: A Reusable Helm Library for Kubernetes Deployments

Steven Hoang — Mon, 18 May 2026 14:30:08 +0000

Introduction

If you've managed multiple microservices on Kubernetes, you've likely felt the pain of maintaining dozens of near-identical Helm charts — each with the same Deployment, Service, Ingress, and HPA templates copied and slightly tweaked. It's tedious, error-prone, and hard to keep consistent.

To solve this, I built drunk.charts — a set of Helm charts anchored by a library chart (drunk-lib) that provides standardized, reusable templates, and a thin application chart (drunk-app) that consumes it. Deploy any application by simply providing a values.yaml — no template duplication required.

All charts are published as OCI artifacts on GitHub Container Registry at oci://ghcr.io/baoduy and are available on Artifact Hub.

Architecture

The design follows Helm's library chart pattern:

drunk-lib (library chart — type: library)
  └── 19 named templates: drunk-lib.<resource-type>
  └── Published as OCI: oci://ghcr.io/baoduy/drunk-lib

drunk-app (application chart — type: application)
  └── Thin wrapper: each template is a single include of drunk-lib.<name>
  └── Declares drunk-lib as a dependency
  └── Published as OCI: oci://ghcr.io/baoduy/drunk-app

This separation means you fix a bug or add a feature in drunk-lib once, bump the version, and every drunk-app deployment inherits it on the next helm dependency update.

drunk-lib: The Library Chart

drunk-lib (v1.3.0) is a Helm library chart — it produces no resources on its own. Instead, it provides named templates that other charts invoke via {{ include "drunk-lib.<name>" . }}.

Available Templates

Category	Template	Resource Generated
Core Workloads	`drunk-lib.deployment`	`apps/v1 Deployment`
	`drunk-lib.statefulset`	`apps/v1 StatefulSet`
Networking	`drunk-lib.service`	`v1 Service`
	`drunk-lib.ingress`	`networking.k8s.io/v1 Ingress`
	`drunk-lib.gateway`	`gateway.networking.k8s.io/v1 Gateway`
	`drunk-lib.httproute`	`gateway.networking.k8s.io/v1 HTTPRoute`
	`drunk-lib.backendTlsPolicy`	`gateway.networking.k8s.io BackendTLSPolicy`
Configuration	`drunk-lib.configMap`	`v1 ConfigMap`
	`drunk-lib.secrets`	`v1 Secret`
	`drunk-lib.secretProviderClass`	`SecretProviderClass` (CSI Driver)
	`drunk-lib.tls-secrets`	`v1 Secret` (TLS type)
Storage	`drunk-lib.volumes`	`v1 PersistentVolumeClaim`
Batch	`drunk-lib.cronjob`	`batch/v1 CronJob`
	`drunk-lib.job`	`batch/v1 Job`
Scaling	`drunk-lib.hpa`	`autoscaling/v2 HorizontalPodAutoscaler`
Security	`drunk-lib.networkPolicy`	`networking.k8s.io/v1 NetworkPolicy`
	`drunk-lib.serviceAccount`	`v1 ServiceAccount`
	`drunk-lib.imagePull-secret`	`v1 Secret` (dockerconfigjson)

Helper Functions

The chart also provides shared helper templates:

app.name / app.fullname — consistent naming across all resources
app.labels — standard Kubernetes labels (app.kubernetes.io/*)
app.selectorLabels — selector labels for pod matching
app.checksums — annotations that trigger pod rollouts when ConfigMap/Secret content changes

How Templates Work

Each template is self-contained and gate-controlled. For example, the Deployment template:

Checks .Values.deployment.enabled — no-op if false
Composes pod metadata using app.labels / app.selectorLabels
Attaches checksum annotations via app.checksums so ConfigMap/Secret changes trigger rollouts
Wires init containers from .Values.global.initContainer
Pulls environment from configMap, secrets, configFrom[], secretFrom[], and CSI secretProvider
Reads scheduling (nodeSelector, affinity, tolerations), security contexts, resources, and volumes from root-level values — shared with sibling resources (Jobs, CronJobs)
Hard-codes automountServiceAccountToken: false for security

Deployment Template — Full Schema

Key	Type	Default	Notes
`deployment.enabled`	bool	`false`	Gate for the entire resource
`deployment.replicaCount`	int	`1`	Pod replicas
`deployment.strategy.type`	string	`RollingUpdate`	`RollingUpdate` or `Recreate`
`deployment.strategy.maxSurge`	int/string	`1`	Rolling update config
`deployment.strategy.maxUnavailable`	int/string	`0`	Rolling update config
`deployment.ports`	map	—	`name: containerPort` pairs
`deployment.command`	list	—	Container command override
`deployment.args`	list	—	Container args override
`deployment.liveness`	string	—	HTTP path for liveness probe
`deployment.readiness`	string	—	HTTP path for readiness probe
`deployment.podAnnotations`	map	—	Extra pod annotations

StatefulSet Template

For workloads requiring stable network identity and persistent storage. Same pod spec composition as Deployment, with added volumeClaimTemplates support and headless Service generation.

Security Defaults

All templates enforce security best practices out of the box:

podSecurityContext:
  fsGroup: 10000
  runAsUser: 10000
  runAsGroup: 10000

securityContext:
  capabilities:
    drop: ["ALL"]
  readOnlyRootFilesystem: true
  runAsNonRoot: true

Using drunk-lib in Your Own Charts

To build a custom chart on top of drunk-lib:

# Chart.yaml
apiVersion: v2
name: my-custom-chart
type: application
dependencies:
  - name: drunk-lib
    version: "1.3.0"
    repository: "oci://ghcr.io/baoduy"

Then in your templates:

# templates/deployment.yaml
{{- include "drunk-lib.deployment" . -}}

# templates/service.yaml
{{- include "drunk-lib.service" . -}}

drunk-app: The Application Chart

drunk-app (v1.3.5) is the ready-to-use chart for deploying applications. It's intentionally a thin wrapper — every template file is a single line:

{{- include "drunk-lib.deployment" . -}}

This means you never write templates. You configure everything through values.yaml.

Installation

# From OCI registry (recommended)
helm install my-app oci://ghcr.io/baoduy/drunk-app --version 1.3.5 -f values.yaml

# Or via Helm repo
helm repo add drunk-charts https://baoduy.github.io/drunk.charts/drunk-app
helm repo update
helm install my-app drunk-charts/drunk-app -f values.yaml

Minimal Deployment

global:
  image: my-registry.azurecr.io/my-app
  tag: "1.0.0"

deployment:
  enabled: true
  ports:
    http: 8080

service:
  type: ClusterIP

volumes:
  - name: tmp
    emptyDir: {}
    mountPath: /tmp

Note: The tmp volume is essential because readOnlyRootFilesystem: true is the default — your app needs a writable /tmp.

Environment Variables and Secrets

# Inline environment variables
env:
  APP_ENV: production
  LOG_LEVEL: info

# Inline secrets (stored as K8s Secret)
secrets:
  DB_CONNECTION: "Server=db;Database=mydb;User=admin;Password=secret"

# Reference existing secrets
secretFrom:
  - name: existing-secret
    key: connection-string
    envName: DB_CONNECTION

# Reference existing configmaps
configFrom:
  - name: shared-config
    key: api-url
    envName: API_URL

Health Checks and Autoscaling

deployment:
  enabled: true
  ports:
    http: 8080
  liveness: /healthz
  readiness: /ready

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70
  targetMemoryUtilizationPercentage: 80

Azure Key Vault Integration (CSI Driver)

secretProvider:
  enabled: true
  tenantId: "your-tenant-id"
  vaultName: "my-keyvault"
  useWorkloadIdentity: true
  objects:
    - name: db-connection-string
      type: secret
      envName: DB_CONNECTION
    - name: api-key
      type: secret
      envName: API_KEY

TLS Secrets Management

Three modes supported:

tlsSecrets:
  # Mode 1: Inline base64-encoded certificates
  - name: my-tls
    cert: <base64-encoded-cert>
    key: <base64-encoded-key>

  # Mode 2: File-based (populate via --set-file during helm install)
  - name: my-tls-file
    certFile: true
    cert: ""
    key: ""

  # Mode 3: CA certificate only (for backend TLS validation)
  - name: my-ca
    ca: <base64-encoded-ca>

Gateway API with TLS Validation

For clusters using the Gateway API instead of traditional Ingress:

httpRoute:
  enabled: true
  hostnames:
    - my-app.drunkcoding.net
  rules:
    - backendRefs:
        - name: my-app
          port: 8080
  parentRefs:
    - name: main-gateway
      namespace: gateway-system
  validation:
    enabled: true
    hostname: my-app.drunkcoding.net
    wellKnownCACertificates: System

CronJobs and Jobs

cronJobs:
  - name: nightly-cleanup
    enabled: true
    schedule: "0 2 * * *"
    command: ["./cleanup.sh"]
    resources:
      limits:
        cpu: 200m
        memory: 256Mi

jobs:
  - name: db-migration
    enabled: true
    command: ["dotnet", "ef", "database", "update"]

Network Policies

networkPolicies:
  - name: allow-ingress-only
    podSelector:
      matchLabels:
        app: my-app
    ingress:
      - from:
          - namespaceSelector:
              matchLabels:
                name: ingress-system
        ports:
          - port: 8080
    policyTypes:
      - Ingress

Init Containers

global:
  image: my-registry.azurecr.io/my-app
  tag: "1.0.0"
  initContainer:
    image: busybox
    tag: latest
    command: ["sh", "-c", "echo initializing"]

Claude Code AI Plugins

Both charts ship with Claude Code plugins that provide AI-assisted configuration. These are available on the Claude Code Plugin Marketplace.

Installing the Plugins

# Add from marketplace
plugin marketplace add baoduy/drunk.charts

drunk-app Plugin

The drunk-app plugin provides an AI assistant with three modes:

Answer — Ask "how does X work?" and get explanations with YAML snippets
Generate — Say "give me a values.yaml for [use case]" and get a complete, validated configuration
Validate — Paste a values.yaml and get a full validation report with fix instructions

Example interactions:

/drunk-app generate a values.yaml for a .NET API with health checks, 
autoscaling, and Azure Key Vault secrets

/drunk-app validate my values.yaml — is the probe configuration correct?

/drunk-app how do I configure multiple network policies?

drunk-lib Plugin

The drunk-lib plugin provides per-template expert skills — 18 specialized assistants, one for each resource type:

Skill	Expertise
`drunk-lib-deployment`	Deployment workloads, rolling updates, pod spec
`drunk-lib-statefulset`	Stateful workloads, headless services, volume claims
`drunk-lib-service`	Service types, port mapping
`drunk-lib-ingress`	Nginx ingress, TLS, path routing
`drunk-lib-httproute`	Gateway API HTTPRoute configuration
`drunk-lib-gateway`	Gateway resource setup
`drunk-lib-backend-tls-policy`	Backend TLS validation
`drunk-lib-hpa`	Horizontal Pod Autoscaler tuning
`drunk-lib-cronjob`	Scheduled batch workloads
`drunk-lib-job`	One-off batch workloads
`drunk-lib-configmap`	ConfigMap from values
`drunk-lib-secrets`	Secret management
`drunk-lib-secretprovider`	CSI Secret Store (Azure Key Vault, AWS)
`drunk-lib-tls-secrets`	TLS certificate management
`drunk-lib-networkpolicy`	Network isolation rules
`drunk-lib-serviceaccount`	ServiceAccount configuration
`drunk-lib-imagepull-secret`	Private registry credentials
`drunk-lib-volumes`	PVC and volume management

Each skill contains the exact values schema consumed by that template, the rendering logic, validation rules, and generation templates — so Claude can produce correct configurations without guessing.

Why a Library Chart?

Approach	Pros	Cons
Copy-paste templates per service	Full control	Drift, maintenance nightmare
Umbrella chart with subcharts	Organized	Heavy, complex dependency management
Library chart + thin wrapper	DRY, consistent, flexible	Slightly opinionated defaults

The library chart pattern gives you:

Single source of truth — fix a bug in drunk-lib, all apps get it on next upgrade
Consistency — every service follows the same security, labeling, and resource patterns
Speed — new services need only a values.yaml, no template work
Flexibility — disable any resource by setting enabled: false
AI-ready — Claude Code plugins understand the exact schema and can generate/validate configs

OCI Distribution

All charts are published to GitHub Container Registry as OCI artifacts:

# Pull directly
helm pull oci://ghcr.io/baoduy/drunk-app --version 1.3.5
helm pull oci://ghcr.io/baoduy/drunk-lib --version 1.3.0

# Use as dependency
# Chart.yaml
dependencies:
  - name: drunk-lib
    version: "1.3.0"
    repository: "oci://ghcr.io/baoduy"

Published packages are visible at github.com/baoduy?tab=packages&repo_name=drunk.charts.

Conclusion

drunk.charts eliminates the boilerplate of Kubernetes deployments while maintaining full flexibility. The drunk-lib library chart provides battle-tested templates with security-first defaults, and drunk-app makes them instantly usable with just a values.yaml. Combined with Claude Code AI plugins that understand the exact schema, you can generate and validate configurations with confidence.

The charts are open source and actively maintained. Contributions and feedback are welcome on GitHub.

[DevOps] Automating Branch Cleanup in Azure DevOps with Node.js

Steven Hoang — Mon, 18 May 2026 14:29:35 +0000

Introduction

As software projects evolve, Git repositories can become cluttered with outdated or redundant branches. This clutter makes repository navigation cumbersome and can introduce confusion or errors in the development process. Automating the cleanup of these branches helps maintain an organized and efficient development environment.

In this guide, we'll walk through setting up a TypeScript script that automatically deletes old, unnecessary branches in Azure DevOps. We'll cover the essential steps, focusing on the implementation and automation of the cleanup process.

Why Automate Branch Cleanup?

Automating branch cleanup is essential for several reasons:

Reduce Clutter: Keeps the repository clean, making it easier for developers to navigate.
Improve Performance: Enhances CI/CD pipeline performance by reducing overhead.
Prevent Confusion: Minimizes the risk of developers working on or merging outdated branches.
Enhance Security: Removes obsolete branches that may contain vulnerabilities.

Prerequisites

Ensure you have the following before starting:

Azure DevOps Account: Access to your organization's Azure DevOps instance.
Personal Access Token (PAT): A PAT with permissions to access and manage repositories.
Node.js and npm: Installed on your machine (Node.js version 14 or later).
TypeScript: Installed globally (npm install -g typescript).
Azure DevOps Node API Package: Install via npm install azure-devops-node-api.
dotenv Package: Install via npm install dotenv.

Project Setup

Create a New Directory: Initialize a new Node.js project.

   mkdir azure-devops-branch-cleanup
   cd azure-devops-branch-cleanup
   npm init -y

Install Dependencies:

   npm install @azure/identity @microsoft/microsoft-graph-client azure-devops-node-api dayjs dotenv
   npm install --save-dev typescript @types/node

Configuration File

Create a config.json file in your project root to specify branches that should be excluded from deletion:

{
  "globalExcludes": ["master", "develop", "main", "release"],
  "repositoryExcludes": {
    "your-repo-name": ["feature/important-branch"]
  }
}

globalExcludes: Branches excluded from deletion across all repositories.
repositoryExcludes: Specific branches to exclude in specific repositories.

Implementing the TypeScript Script

Create a TypeScript file, e.g., cleanup.ts, and implement the following steps:

1. Loading Environment Variables

Use the dotenv package to load environment variables.

import * as dotenv from "dotenv";
dotenv.config();

const isDryRun = process.env.DryRun === "true";

Environment Variables Required:

AZURE_DEVOPS_URL: Your Azure DevOps organization URL.
AZURE_DEVOPS_PAT: Your Personal Access Token.
AZURE_DEVOPS_PROJECT: Your project name.
DryRun: Set to "true" for dry-run mode (no actual deletions).

2. Defining the Configuration Interface

Define an interface to ensure type safety.

interface Config {
  globalExcludes: string[];
  repositoryExcludes: {
    [repoName: string]: string[];
  };
}

3. Setting Constants

Define constants used in the script.

const DAYS_90_MS = 90 * 24 * 60 * 60 * 1000; // 90 days in milliseconds

4. Getting the Git API Client

Authenticate and obtain the Git API client.

import * as azdev from "azure-devops-node-api";
import * as GitApi from "azure-devops-node-api/GitApi";

async function getGitApi(): Promise<GitApi.IGitApi> {
  const orgUrl = process.env.AZURE_DEVOPS_URL;
  const token = process.env.AZURE_DEVOPS_PAT;

  if (!orgUrl || !token) {
    throw new Error(
      "Azure DevOps URL or PAT is not set in environment variables."
    );
  }

  const authHandler = azdev.getPersonalAccessTokenHandler(token);
  const connection = new azdev.WebApi(orgUrl, authHandler);
  return await connection.getGitApi();
}

5. Loading the Configuration

Load the config.json file.

import * as fs from "fs";
import * as path from "path";

function loadConfig(): Config {
  const configPath = path.join(__dirname, "config.json");
  const configContent = fs.readFileSync(configPath, "utf-8");
  return JSON.parse(configContent) as Config;
}

6. Retrieving Repositories and Branches

Get the list of repositories and branches.

import * as GitInterfaces from "azure-devops-node-api/interfaces/GitInterfaces";

async function getRepositories(
  gitApi: GitApi.IGitApi,
  project: string
): Promise<GitInterfaces.GitRepository[]> {
  return await gitApi.getRepositories(project);
}

async function getBranches(
  gitApi: GitApi.IGitApi,
  project: string,
  repoId: string
): Promise<GitInterfaces.GitRef[]> {
  const branches = await gitApi.getRefs(repoId, project);
  return branches.filter(b => b.name.startsWith("refs/heads/"));
}

7. Determining the Last Commit Date

Get the date of the last commit on a branch.

async function getLastCommitDate(
  gitApi: GitApi.IGitApi,
  project: string,
  repoId: string,
  branchName: string
): Promise<Date | null> {
  const commits = await gitApi.getCommits(
    repoId,
    { itemVersion: { version: branchName } },
    project,
    undefined,
    1
  );

  if (commits.length > 0) {
    const commitDate = commits[0].committer.date || commits[0].author.date;
    return new Date(commitDate);
  }

  return null;
}

8. Checking if a Branch is Merged

Check if a branch is merged into any of the target branches.

import { GitVersionType } from "azure-devops-node-api/interfaces/GitInterfaces";

async function isBranchMerged(
  gitApi: GitApi.IGitApi,
  project: string,
  repoId: string,
  branch: string,
  targetBranches: string[]
): Promise<boolean> {
  for (const targetBranch of targetBranches) {
    const diff = await gitApi.getCommitDiffs(
      repoId,
      project,
      true,
      1,
      undefined,
      { baseVersionType: GitVersionType.Branch, baseVersion: branch },
      { targetVersionType: GitVersionType.Branch, targetVersion: targetBranch }
    );

    if (diff && diff.aheadCount === 0) {
      return true;
    }
  }
  return false;
}

9. Deleting a Branch

Delete the branch if it meets the criteria.

async function deleteBranch(
  gitApi: GitApi.IGitApi,
  project: string,
  repoId: string,
  branch: GitInterfaces.GitRef
): Promise<void> {
  if (!isDryRun) {
    if (branch.isLocked) {
      await gitApi.updateRef(
        { name: branch.name, isLocked: false },
        repoId,
        "",
        project
      );
    }

    await gitApi.updateRefs(
      [
        {
          name: branch.name,
          newObjectId: "0000000000000000000000000000000000000000",
          oldObjectId: branch.objectId,
        },
      ],
      repoId,
      "",
      project
    );
  }

  console.log(`Deleted branch: ${branch.name} (Dry Run: ${isDryRun})`);
}

10. Compiling the Exclusion List

Combine global and repository-specific exclusions.

function getExclusionList(config: Config, repoName: string): string[] {
  const globalExcludes = config.globalExcludes || [];
  const repoSpecificExcludes = config.repositoryExcludes[repoName] || [];
  return [...new Set([...globalExcludes, ...repoSpecificExcludes])];
}

11. Cleaning Up Branches

Main function orchestrating the cleanup.

async function cleanUpBranches(): Promise<void> {
  const project = process.env.AZURE_DEVOPS_PROJECT;
  if (!project) {
    throw new Error(
      "Azure DevOps project name is not set in environment variables."
    );
  }

  const config = loadConfig();
  const now = new Date();
  const gitApi = await getGitApi();
  const repositories = await getRepositories(gitApi, project);

  for (const repo of repositories) {
    console.log(`Processing repository: ${repo.name}`);
    const excludeBranches = getExclusionList(config, repo.name);
    const branches = await getBranches(gitApi, project, repo.id);

    for (const branch of branches) {
      const branchName = branch.name.replace("refs/heads/", "");

      if (excludeBranches.includes(branchName)) {
        console.log(`Skipping excluded branch: ${branchName}`);
        continue;
      }

      const lastCommitDate = await getLastCommitDate(
        gitApi,
        project,
        repo.id,
        branchName
      );

      if (
        !lastCommitDate ||
        now.getTime() - lastCommitDate.getTime() < DAYS_90_MS
      ) {
        console.log(`Branch is recent or active: ${branchName}`);
        continue;
      }

      const isMerged = await isBranchMerged(
        gitApi,
        project,
        repo.id,
        branchName,
        config.globalExcludes
      );

      if (isMerged) {
        await deleteBranch(gitApi, project, repo.id, branch);
      } else {
        console.log(`Branch is not merged: ${branchName}`);
      }
    }
  }
}

cleanUpBranches().catch(err => {
  console.error("An error occurred:", err);
});

Automating with Azure DevOps Pipeline

To automate the script execution, set up an Azure DevOps Pipeline.

Create a Variable Group:

Navigate to Pipelines > Library in Azure DevOps.
Click "Variable groups" > "Add variable group".
Name the group, e.g., az-devops.
Add the variables:
- AZURE_DEVOPS_URL
- AZURE_DEVOPS_PAT (set as secret)
- AZURE_DEVOPS_PROJECT
Save the variable group.

Create the Pipeline YAML File:

Create a azure-pipelines.yml file in your repository:

   trigger: none

   schedules:
     - cron: "0 0 * * 0" # Runs every Sunday at 00:00
       displayName: "Weekly Branch Cleanup"
       branches:
         include:
           - main
       always: true
       batch: false

   pool:
     vmImage: ubuntu-latest

   variables:
     - group: az-devops

   steps:
     - task: NodeTool@0
       inputs:
         versionSpec: "14.x"
       displayName: "Install Node.js"

     - script: |
         npm ci
         npx ts-node cleanup.ts
       displayName: "Run Branch Cleanup Script"
       env:
         AZURE_DEVOPS_URL: $(AZURE_DEVOPS_URL)
         AZURE_DEVOPS_PAT: $(AZURE_DEVOPS_PAT)
         AZURE_DEVOPS_PROJECT: $(AZURE_DEVOPS_PROJECT)

Notes:
- Replace cleanup.ts with the path to your script.
- Ensure the pipeline has access to the variable group.

Conclusion

Automating branch cleanup ensures your repositories remain organized, improving developer productivity and reducing potential errors. By following this guide, you can set up a script to automatically identify and delete old, unused branches in Azure DevOps, and schedule it using Azure Pipelines for regular maintenance.

Benefits:

Efficiency: Saves time and resources.
Consistency: Maintains a consistent repository state.
Scalability: Easily extends to multiple projects and repositories.

Additional Resources

Full Working Source Code: drunkcoding public code
Azure DevOps Node API Documentation: Git API Reference
Azure DevOps REST API Reference: Git Repositories

Note: Always test scripts in a controlled environment before deploying them in production. Ensure compliance with your organization's policies and procedures.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[Tools] Cleaning Up Azure Service Bus Dead-Letter Queues with .NET

Steven Hoang — Mon, 18 May 2026 14:29:01 +0000

Introduction

In cloud-based applications, message queues are critical for enabling reliable, asynchronous communication between services. Azure Service Bus is a robust messaging platform that facilitates this communication in distributed systems. However, messages that cannot be processed or delivered successfully may end up in the Dead-Letter Queue (DLQ). If left unmanaged, these dead-letter messages can accumulate, leading to storage issues and degraded system performance.

In this article, we'll explore the importance of regularly cleaning up dead-letter queues in Azure Service Bus. We'll guide you through implementing a .NET background service that automates this cleanup process by moving dead-letter messages to Azure Blob Storage. This approach ensures your messaging system remains efficient while preserving problematic messages for future analysis or reprocessing.

Understanding Dead-Letter Queues

A Dead-Letter Queue (DLQ) is a sub-queue associated with each Azure Service Bus entity (queue or topic subscription). It holds messages that cannot be delivered or processed successfully. Messages may be moved to the DLQ for several reasons:

Exceeding Maximum Delivery Attempts: A message is retried multiple times but still cannot be processed successfully.
Message Expiration: The message's Time to Live (TTL) expires before it is processed.
Filter Violations: The message does not match the filter criteria of a subscription.
Processing Errors: An application explicitly moves a message to the DLQ due to a processing failure.

By design, the DLQ provides a way to isolate faulty messages, allowing your system to continue processing valid messages without interruption.

Why Regularly Clean Up Dead-Letter Messages?

1. Prevent Storage Overruns

Dead-letter messages accumulate over time, consuming storage resources. If left unchecked, this can lead to a QuotaExceededException, where the maximum size limit for a Service Bus entity is reached:

Microsoft.Azure.ServiceBus.QuotaExceededException:
The maximum entity size has been reached or exceeded for Topic:
'YourTopicName'. Size of entity in bytes: 2147489161, Max entity size in bytes: 2147483648.

This exception can disrupt normal operations, preventing new messages from being sent or received.

2. Maintain System Performance and Reliability

Large volumes of dead-letter messages can degrade the performance of your Service Bus namespace. They can slow down operations such as message retrieval and monitoring, leading to bottlenecks in your system.

3. Enable Effective Error Handling and Analysis

By archiving dead-letter messages to Azure Blob Storage, you retain the ability to analyze and diagnose issues without impacting the performance of your messaging system. This allows your team to:

Investigate Failures: Understand why messages failed and identify patterns.
Reprocess Messages: Correct issues and resend messages if necessary.
Improve Resilience: Implement fixes to prevent similar failures in the future.

Implementing a Dead-Letter Cleanup Service with .NET

To automate the cleanup process, we'll create a .NET background service that:

Retrieves dead-letter messages from all queues and topic subscriptions.
Archives messages to Azure Blob Storage.
Deletes messages from the DLQ after successful archiving.

Prerequisites

Azure Service Bus Namespace: With appropriate permissions (Manage rights) to access queues and topics.
Azure Storage Account: For storing archived dead-letter messages.
.NET 6 SDK: Installed on your development machine.
Docker: (Optional) For containerized deployment.

Getting the Source Code

The source code for the cleanup tool is available on GitHub:

Repository: Azure Service Bus Dead-Letter Cleanup Tool

Service Configuration

The service uses an appsettings.json file for configuration:

{
  "ServiceBus": {
    "ConnectionString": "YOUR_SERVICE_BUS_CONNECTION_STRING"
  },
  "StorageAccount": {
    "ConnectionString": "YOUR_STORAGE_ACCOUNT_CONNECTION_STRING",
    "ContainerName": "bus-dead-letters"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning"
    }
  }
}

ServiceBus:
- ConnectionString: Your Azure Service Bus connection string with Manage permissions.
StorageAccount:
- ConnectionString: Your Azure Storage Account connection string.
- ContainerName: The name of the Blob Storage container where dead-letter messages will be stored.

Security Note: For production environments, consider using Azure Key Vault or environment variables to securely manage connection strings.

How the Cleanup Service Works

Connect to Azure Service Bus: The service connects to your Service Bus namespace using the provided connection string.
Discover Entities: It retrieves all queues and topic subscriptions in the namespace.
Process Dead-Letter Messages:

For each entity, it checks the DLQ for messages.
If messages are found, it reads them and saves each message as a JSON file in Azure Blob Storage.
The messages are organized in folders by entity name and date, making them easy to locate.

Delete Processed Messages: After successfully archiving, the messages are deleted from the DLQ.

Archiving Structure in Blob Storage

The messages are stored in Azure Blob Storage with the following structure:

bus-dead-letters/
├── queues/
│   ├── queue1/
│   │   └── 2023-09-20/
│   │       ├── message1.json
│   │       └── message2.json
│   └── queue2/
│       └── 2023-09-20/
│           └── message1.json
└── topics/
    ├── topic1/
    │   ├── subscription1/
    │   │   └── 2023-09-20/
    │   │       └── message1.json
    │   └── subscription2/
    │       └── 2023-09-20/
    │           └── message1.json

Setting Up the Service

Option 1: Running Locally

Clone the Repository:

   git clone https://github.com/baoduy/tool-serviceBus-deadLetters-cleanup.git
   cd tool-serviceBus-deadLetters-cleanup

Configure the Service:

Update appsettings.json with your connection strings.
Alternatively, set the environment variables ServiceBus__ConnectionString, StorageAccount__ConnectionString, and StorageAccount__ContainerName.

Build and Run the Service:

   dotnet build
   dotnet run

Option 2: Using Docker

A Docker image is available for easy deployment:

Docker Image: baoduy2412/servicebus-cleanup

Running with Docker Compose

Create a docker-compose.yml file:

version: "3.8"

services:
  servicebus-cleanup:
    image: baoduy2412/servicebus-cleanup:latest
    environment:
      ServiceBus__ConnectionString: YOUR_SERVICE_BUS_CONNECTION_STRING
      StorageAccount__ConnectionString: YOUR_STORAGE_ACCOUNT_CONNECTION_STRING
      StorageAccount__ContainerName: bus-dead-letters
    restart: unless-stopped

Run the service:

docker-compose up -d

Running with Docker Command Line

docker run -d \
  -e ServiceBus__ConnectionString=YOUR_SERVICE_BUS_CONNECTION_STRING \
  -e StorageAccount__ConnectionString=YOUR_STORAGE_ACCOUNT_CONNECTION_STRING \
  -e StorageAccount__ContainerName=bus-dead-letters \
  baoduy2412/servicebus-cleanup:latest

Managing Storage Costs with Lifecycle Policies

Over time, archived messages in Blob Storage can accumulate and consume significant storage space. To manage this:

Set Up Lifecycle Management:

In the Azure Portal, navigate to your Storage Account.
Select Lifecycle management under Blob service.

Create a Rule:

Name: e.g., DeleteOldArchivedMessages.
Scope: Apply to the container bus-dead-letters.
Filter: Optionally specify filters if needed.
Action: Delete blobs older than a specified number of days (e.g., 30 days).

Save the Rule: Azure will automatically delete archived messages older than the specified retention period.

Conclusion

Dead-letter queues are an integral part of Azure Service Bus, providing a mechanism to handle messages that cannot be processed. However, without regular maintenance, they can lead to storage overruns and impact system performance.

By implementing the .NET background service described in this article, you can automate the cleanup of dead-letter queues:

Automated Cleanup: Keeps DLQs empty, preventing storage issues.
Message Archiving: Stores messages for future analysis without impacting Service Bus performance.
Scalability: The tool operates at the namespace level, handling all queues and topics automatically.
Cost Management: Utilizes storage lifecycle policies to control storage costs.

This approach ensures your messaging system remains reliable and efficient while preserving valuable data for troubleshooting and improvement.

Additional Resources

GitHub Repository: Azure Service Bus Dead-Letter Cleanup Tool
Docker Image: baoduy2412/servicebus-cleanup
Azure Service Bus Documentation:
- Dead-letter Queues
- Service Bus Quotas and Limits
Azure Blob Storage:
- Lifecycle Management Overview
- Optimize Costs by Automating Data Lifecycle Management

By automating dead-letter queue management, you enhance the stability and maintainability of your messaging infrastructure, ensuring it continues to meet the demands of your applications.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[AZ] How to Scan and Disable Inactive Accounts on Azure EntraID

Steven Hoang — Mon, 18 May 2026 14:28:13 +0000

Introduction

As organizations grow, so does the number of user accounts within their systems. Managing these accounts efficiently is crucial for maintaining security and compliance. In particular, inactive accounts in Azure Entra ID (formerly known as Azure Active Directory) can pose significant security risks. These dormant accounts are potential entry points for malicious actors seeking unauthorized access to sensitive data.

In this comprehensive guide, we'll walk through how to automate the management of inactive Azure Entra ID accounts using a TypeScript application. We'll cover everything from setting up an Azure Entra ID application, implementing the TypeScript program, to scheduling the script using Azure DevOps for regular execution.

Understanding the Risks of Inactive Accounts
Creating an Azure Entra ID Application
Implementing the TypeScript Program
Scheduling the Script with Azure DevOps
Conclusion

1. Understanding the Risks of Inactive Accounts

Inactive accounts are user accounts that haven't been used for a significant period. They can accumulate due to employee turnover, role changes, or users simply forgetting about them. These accounts are risky because:

Security Vulnerabilities: They might have weak or outdated passwords, making them easy targets.
Unauthorized Access: If compromised, they can provide unauthorized access to internal systems and data.
Compliance Issues: Regulations often require the timely removal or deactivation of unused accounts.

Regularly auditing and managing these accounts helps mitigate these risks and ensures compliance with security best practices.

2. Creating an Azure Entra ID Application

To interact with Azure Entra ID programmatically, we'll create an App Registration.
This application will authenticate and manage user accounts via the Microsoft Graph API.

Steps to Create an App Registration

1. Navigate to Azure Entra ID

Log in to the Azure portal.
In the left-hand navigation pane, select Azure Entra ID.

2. Create a New App Registration

Click on "App registrations" in the sidebar.
Click on "New registration" at the top.

3. Configure the App Registration

Name: Enter a meaningful name, e.g., Azure-EntraID-Management app.
Supported account types: Choose "Accounts in this organizational directory only (Single tenant)".
Redirect URI: This is not required for our application, so you can leave it blank.
Click "Register" to create the app.

Adding API Permissions

After creating the app registration, we need to grant it permissions to access the Microsoft Graph API.

1. Navigate to API Permissions

In the app registration's overview page, click on "API permissions" in the sidebar.

2. Add Permissions

Click on "Add a permission".
Select "Microsoft Graph".
Choose "Application permissions" since this app will run as a background service or daemon.

3. Select Required Permissions

Search for and select the following permissions:

AuditLog.Read.All: Allows the app to read all audit log data.
User.Read.All: Allows the app to read user profiles.
User.ReadWrite.All: Allows the app to read and write user profiles.

Note: The User.ReadWrite.All permission is required to enable or disable user accounts.

4. Grant Admin Consent

After adding the permissions, click on "Grant admin consent for [Your Tenant Name]".
Confirm by clicking "Yes" in the prompt.

5. Create a Client Secret

Navigate to "Certificates & secrets".
Click on "New client secret".
Provide a description and set an expiration period.
Click "Add".
Copy the Value of the client secret and store it securely. You won't be able to view it again.

Collect Necessary Information

You'll need the following information for your application:

Tenant ID: Found in Azure Entra ID > Properties.
Client ID: Found in your app registration's Overview page.
Client Secret: The value you just created.

3. Implementing the TypeScript Program

We'll create a TypeScript program that:

Authenticates with Azure Entra ID using the app registration.
Retrieves inactive user accounts based on their last sign-in date.
Disables these inactive accounts.
Generates a report of all disabled accounts.

Setting Up the Project

1. Initialize the Project

Create a new directory for your project and initialize npm:

mkdir azure-entra-id-management
cd azure-entra-id-management
npm init -y

2. Install Dependencies

Install the required packages:

npm install @azure/identity @microsoft/microsoft-graph-client dayjs
npm install --save-dev typescript ts-node

@azure/identity: Provides Azure authentication methods.
@microsoft/microsoft-graph-client: Allows interaction with Microsoft Graph API.
dayjs: A lightweight library for date manipulation.
typescript and ts-node: Required for compiling and running TypeScript code.

3. Configure TypeScript

Create a tsconfig.json file:

{
  "compilerOptions": {
    "module": "commonjs",
    "esModuleInterop": true,
    "target": "es6",
    "moduleResolution": "node",
    "sourceMap": true,
    "outDir": "dist"
  },
  "lib": ["es2015"],
  "files": ["index.ts"]
}

Writing Code

1. Create the Source File and Import Required Modules

At the top of index.ts, import the necessary modules:

import { DefaultAzureCredential } from "@azure/identity";
import { Client } from "@microsoft/microsoft-graph-client";
import { TokenCredentialAuthenticationProvider } from "@microsoft/microsoft-graph-client/authProviders/azureTokenCredentials";
import dayjs from "dayjs";

Note: The isomorphic-fetch import is necessary for environments where fetch is not available globally.

2. Set Configuration Variables

Define the configuration variables and excluded accounts:

// Configuration
const INACTIVITY_THRESHOLD_MONTHS = 2; // Adjust as needed
const EXCLUDED_ACCOUNTS = ["admin@example.com", "serviceaccount@example.com"];

// Azure AD App Credentials - Replace with your actual credentials or use environment variables
const TENANT_ID = process.env.AZURE_TENANT_ID;
const CLIENT_ID = process.env.AZURE_CLIENT_ID;
const CLIENT_SECRET = process.env.AZURE_CLIENT_SECRET;

Security Tip: Never hard-code credentials. Use environment variables or secure credential management.

3. Set Up Authentication and Client

Create a ClientSecretCredential and initialize the Microsoft Graph client:

if (!TENANT_ID || !CLIENT_ID || !CLIENT_SECRET) {
  throw new Error(
    "Please ensure AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET are set."
  );
}

/** 1. Setup Credentials and Microsoft Graph client */
const client = Client.initWithMiddleware({
  debugLogging: false,
  authProvider: new TokenCredentialAuthenticationProvider(
    // This DefaultAzureCredential will detect the credentials from environment variables above automatically.
    new DefaultAzureCredential(),
    {
      scopes: ["https://graph.microsoft.com/.default"],
    }
  ),
});

4. Define Types

Define types for the Azure AD user and result:

type AzResult<T> = { value: Array<T> };
type AdUser = {
  userPrincipalName: string;
  id: string;
  accountEnabled: boolean;
};

5. Implement Functions

a. Retrieve Inactive Accounts

async function getInactiveAccounts(cutoffDate: Dayjs): Promise<AdUser[]> {
  /** Query all the accounts that has signInActivity date before the expected parameter date */
  const accounts = (await client
    .api("/users/")
    .filter(`signInActivity/lastSignInDateTime lt ${cutoffDate.toISOString()}`)
    .select("id,userPrincipalName,accountEnabled")
    .get()) as AzResult<AdUser>;

  /** Filter the enabled account only here
   * as the API filter has limitation that not allows to query based on both signInActivity and accountEnabled */
  return accounts.value.filter(m => m.accountEnabled);
}

Note: The Microsoft Graph API may paginate results. The loop ensures all pages are retrieved.

b. Disable Accounts

async function disableAccounts(users: AdUser[]): Promise<void> {
  return await Promise.all(
    accounts.map(async u => {
      /* Check and keep the account if found in the excludedAccounts */
      if (
        EXCLUDED_ACCOUNTS.find(a =>
          u.userPrincipalName.toLowerCase().includes(a.toLowerCase())
        )
      ) {
        console.log(
          `User account ${u.userPrincipalName} has been excluded from disabling.`
        );
        return;
      }

      // Perform the account disabling
      await client.api(`/users/${u.id}`).update({
        accountEnabled: false,
      });

      console.log(
        `User account with ID ${u.userPrincipalName} has been disabled.`
      );
    })
  );
}

c. Retrieve Disabled Accounts

async function getDisabledAccounts(): Promise<AdUser[]> {
  /** Query all the accounts that has accountEnabled is false */
  const rs = (await client
    .api("/users/")
    .filter(`accountEnabled eq false`)
    .select("id,userPrincipalName,accountEnabled")
    .get()) as AzResult<AdUser>;

  return rs.value;
}

d. Print Accounts

function printAccounts(message: string, accounts: AdUser[]): void {
  console.log(message);
  accounts.forEach((user, index) => {
    console.log(
      `${index + 1}. ${user.userPrincipalName} (Enabled: ${user.accountEnabled})`
    );
  });
}

6. Main Execution Function

Finally, create the main function to orchestrate the process:

(async () => {
  try {
    //1. Scanning account that inactive for more than 2 months
    const cutoffDate = dayjs().subtract(INACTIVITY_THRESHOLD_MONTHS, "month");
    console.log(
      `Scanning for accounts inactive since before ${cutoffDate.format("YYYY-MM-DD")}...\n`
    );

    // Retrieve inactive accounts
    const inactiveAccounts = await getInactiveAccounts(cutoffDate);
    printAccounts(
      `Found ${inactiveAccounts.length} inactive account(s):`,
      inactiveAccounts
    );

    // Disable inactive accounts
    if (inactiveAccounts.length > 0) {
      await disableAccounts(inactiveAccounts);
    } else {
      console.log("No inactive accounts to disable.");
    }

    // Retrieve and print disabled accounts
    const disabledAccounts = await getDisabledAccounts();
    printAccounts(`\nCurrently disabled accounts:`, disabledAccounts);
  } catch (error) {
    console.error("An error occurred:", error);
  }
})();

7. Running the Program

Ensure the environment variables are set:

export AZURE_TENANT_ID=your_tenant_id
export AZURE_CLIENT_ID=your_client_id
export AZURE_CLIENT_SECRET=your_client_secret

Compile and run the program:

npx ts-node src/index.ts

4. Scheduling the Script with Azure DevOps

To automate the execution of the script, we'll use Azure DevOps to schedule it as part of a pipeline.

Steps to Schedule the Script

1. Commit the Code to a Repository

Create a Git repository in Azure DevOps.
Commit all your code, including the package.json, tsconfig.json, and src directory.

2. Create a Variable Group

Navigate to Pipelines > Library in Azure DevOps.

Click "Variable groups" and then "Add variable group".
Name the variable group, e.g., AzureEntraIDCredentials.
Add the following variables:
- AZURE_TENANT_ID
- AZURE_CLIENT_ID
- AZURE_CLIENT_SECRET
For each variable, enter the corresponding value and mark it as secret.
Save the variable group.

3. Create the Pipeline

In Pipelines, click "Create Pipeline" and follow the prompts to set up a YAML pipeline.

a. Define the YAML Pipeline

Create a azure-pipelines.yml file in your repository with the following content:

trigger: none

schedules:
  - cron: "0 0 * * 0" # Runs at midnight every Sunday
    displayName: "Weekly Sunday Run"
    branches:
      include:
        - main
    always: true
    batch: false

pool:
  vmImage: "ubuntu-latest"

variables:
  - group: AzureEntraIDCredentials

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: "14.x" # Adjust Node.js version as needed
    displayName: "Install Node.js"

  - script: |
      npm ci
      npx ts-node src/index.ts
    displayName: "Install dependencies and run script"
    env:
      AZURE_TENANT_ID: $(AZURE_TENANT_ID)
      AZURE_CLIENT_ID: $(AZURE_CLIENT_ID)
      AZURE_CLIENT_SECRET: $(AZURE_CLIENT_SECRET)

b. Pipeline Explanation

Trigger: Set to none to prevent automatic builds on code changes.
Schedules: Configured to run every Sunday at midnight.
Pool: Uses the latest Ubuntu VM image.
Variables: Includes the variable group with your credentials.
Steps:
- NodeTool: Ensures Node.js is available on the agent.
- Script: Installs dependencies and runs the script.

4. Run and Monitor the Pipeline

Save and run the pipeline manually to test it.
Monitor the pipeline's execution in the Pipelines section.
Ensure that the script runs successfully and performs the expected actions.

5. Secure the Pipeline

Permissions: Ensure only authorized personnel can modify the pipeline and variable group.
Secret Variables: Keep your credentials secure by marking them as secrets and avoiding logging sensitive information.

5. Conclusion

Automating the management of inactive Azure Entra ID accounts enhances your organization's security posture by reducing potential attack surfaces. By leveraging TypeScript and Azure DevOps, you can create a scalable and maintainable solution that integrates seamlessly with your existing workflows.

You can refer the Full Working Source Code here: drunkcoding public code

Key Takeaways

Security First: Regularly auditing and managing inactive accounts is critical for security and compliance.
Automation: Automating tasks reduces manual effort and the likelihood of human error.
Scalability: Using TypeScript and Azure DevOps allows for easy updates and scalability as your organization grows.

Next Topic

Enhancements: Extend the script to send email notifications before disabling accounts.
Logging: Integrate logging mechanisms for better auditing and monitoring.
Policy Compliance: Ensure the solution complies with your organization's policies and any applicable regulations.

Important: Accessing certain Microsoft Graph API endpoints requires appropriate licensing. Ensure you have the necessary Microsoft Entra ID P2 or equivalent licenses to use the AuditLog API and other premium features.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[Tools] Automating Let's Encrypt Certificate Management with Azure Key Vault and Cloudflare

Steven Hoang — Mon, 18 May 2026 14:27:55 +0000

Introduction

Custom domain names enhance the professionalism and credibility of applications hosted on Azure services.
However, associating a custom domain requires a trusted SSL/TLS certificate. For development and sandbox environments
used internally by development teams, leveraging Let's Encrypt certificates offers a convenient and automated solution.
Let's Encrypt provides free SSL certificates, but they have a short lifespan of only 90 days, necessitating frequent renewals.

To streamline this process, I've developed a tool that automates the generation and renewal of Let's Encrypt certificates specifically for development
and sandbox environments. The tool detects expiring certificates and renews only those that are nearing expiration, ensuring efficient management.
The new certificates are securely imported into Azure Key Vault, allowing seamless integration with Azure resources such as Azure API Management
and Azure Front Door. To eliminate manual intervention entirely, the tool runs as a monthly cron job on Azure Kubernetes Service (AKS).

Why Automate Certificate Management?

Manually managing short-lived Let's Encrypt SSL certificates can be time-consuming and error-prone, especially when dealing with multiple domains
and environments. Automating the certificate management process offers several significant advantages:

Cost Savings for Development and Sandbox Environments: Let's Encrypt provides a free alternative to paid certificates,
making it ideal for non-production environments where cost optimization is important.
Elimination of Certificate Expiration Concerns: The tool proactively identifies and renews certificates nearing expiration,
ensuring your services remain secure without requiring manual intervention.
Simplified Management of Multiple Domains: With built-in support for handling multiple domains via Cloudflare,
the tool streamlines the process of managing DNS challenges required for certificate validation.
Secure Integration with Azure Key Vault: Automatically importing generated certificates into Azure Key Vault provides a secure
and centralized storage solution, enhancing overall security and simplifying certificate management across your Azure resources.

How It Works

The tool automates SSL certificate management by running as a monthly cron job on AKS. It handles the entire lifecycle of SSL certificates, from detection of impending expiration to deployment of new certificates. The workflow is as follows:

Check Certificate Expiration: The tool scans all certificates stored in Azure Key Vault to determine their expiration dates.
Generate New Certificates: For certificates nearing expiration, the tool requests new SSL certificates from Let's Encrypt.
DNS Challenge via Cloudflare: The tool integrates with Cloudflare to perform DNS challenges required by Let's Encrypt to validate domain ownership.
Import Certificates to Azure Key Vault: The newly obtained certificates are securely imported into Azure Key Vault, replacing the old certificates.
Automated Monthly Execution: The tool is scheduled to run monthly on AKS, ensuring that certificates are kept up-to-date with minimal manual effort.

Setting Up Cloudflare DNS API Token

To enable the tool to perform DNS challenges for domain validation, you need to create a Cloudflare API token with permissions to manage DNS records.

Create an API Token:

Log in to your Cloudflare account and navigate to your profile.
Go to the API Tokens section or directly via this link.
Click on "Create Token".

Configure Token Permissions:

Permissions: Grant Zone > DNS > Edit permissions.
Zone Resources: Select Specific Zone and choose the domain(s) you want to manage.

Client IP Address Filtering (Optional but Recommended):

For enhanced security, specify the AKS cluster's public IP address under "Client IP Address Filtering" in the token settings.
This restricts API token usage to requests originating from your AKS cluster, preventing unauthorized access.

Save the Token:

Generate the token and copy it. You'll need it for the tool's configuration.

Configuration

The tool is configured using environment variables or a JSON configuration file. Here's an example appsettings.json file:

{
  "CertManager": {
    "ProductionEnabled": true,
    "CfEmail": "your-cloudflare-email@example.com",
    "CfToken": "YOUR_CLOUDFLARE_API_TOKEN",
    "ZoneId": "YOUR_CLOUDFLARE_ZONE_ID",
    "LetsEncryptEmail": "your-email@example.com",
    "Domains": ["api.example.com", "*.example.com"],
    "CertInfo": {
      "CountryName": "SG",
      "State": "Singapore",
      "Locality": "Singapore",
      "Organization": "YourOrganization",
      "OrganizationUnit": "YourUnit"
    },
    "KeyVaultUrl": "https://your-keyvault-name.vault.azure.net/",
    "KeyVaultUID": "OPTIONAL_USER_ASSIGNED_IDENTITY_CLIENT_ID"
  }
}

Configuration Parameters Explained:

ProductionEnabled: Set to true to use Let's Encrypt production environment. Set to false for testing purposes.
CfEmail: Your Cloudflare account email address.
CfToken: The Cloudflare API token created earlier.
ZoneId: The ID of your Cloudflare DNS zone. You can find this in your Cloudflare dashboard under the domain's Overview section.
LetsEncryptEmail: An email address for Let's Encrypt notifications.
Domains: An array of domains and subdomains for which you want to generate certificates.
CertInfo: Certificate subject information.
KeyVaultUrl: The URL of your Azure Key Vault where certificates will be stored.
KeyVaultUID: The Client ID of the User Assigned Managed Identity (UAMI) used by your AKS cluster (optional if using the default identity).

Deploying to AKS

Prerequisites

An AKS cluster where the tool will run.
The AKS cluster's agent pool has a User Assigned Managed Identity (UAMI) for Azure resource authentication.
Access to the Azure Key Vault where certificates will be stored.

Granting Key Vault Access to AKS UAMI

Before deploying the tool, you need to grant your AKS cluster's UAMI the necessary permissions to access Azure Key Vault:

Identify the AKS Agent Pool UAMI:

In the Azure portal, navigate to your AKS cluster.
Under Settings, select Identity.
Note the Client ID of the User Assigned identity associated with your node pools.

Grant Key Vault Permissions:

Navigate to your Azure Key Vault.
Select Access control (IAM).
Click on "Add role assignment".
In the Role dropdown, select "Key Vault Certificates Officer".
Click Next and select the AKS UAMI as the Member.
Review and assign the role.

By granting the Key Vault Certificates Officer role to your AKS UAMI, you allow the tool running on AKS to manage certificates within the Key Vault.

Deploying the Tool Using Helm

Assuming you are using Helm for deployment, you can update your Helm chart values file with the necessary configurations.

Here's an example values.yaml file:

services:
  cert-renewal:
    image: baoduy2412/keyvault-letsencrypt:latest
    environment:
      CertManager__ProductionEnabled: "true"
      CertManager__CfEmail: "your-cloudflare-email@example.com"
      CertManager__CfToken: "YOUR_CLOUDFLARE_API_TOKEN"
      CertManager__ZoneId: "YOUR_CLOUDFLARE_ZONE_ID"
      CertManager__LetsEncryptEmail: "your-email@example.com"
      CertManager__Domains__0: "api.example.com"
      CertManager__Domains__1: "*.example.com"
      CertManager__CertInfo__CountryName: "SG"
      CertManager__CertInfo__State: "Singapore"
      CertManager__CertInfo__Locality: "Singapore"
      CertManager__CertInfo__Organization: "YourOrganization"
      CertManager__CertInfo__OrganizationUnit: "YourUnit"
      CertManager__KeyVaultUrl: "https://your-keyvault-name.vault.azure.net/"
      CertManager__KeyVaultUID: "OPTIONAL_USER_ASSIGNED_IDENTITY_CLIENT_ID"
    schedule: "0 0 1 * *" # Runs on the 1st of every month at midnight

Notes:

Image: Ensure you're using the correct Docker image.
Environment Variables: Update all placeholders with your actual configuration values.
Schedule: The cron expression "0 0 1 * *" schedules the job to run at midnight on the first day of every month.

Deploying the Helm Chart

Update Helm Repositories:

   helm repo update

Deploy or Upgrade the Chart:

   helm upgrade --install cert-renewal ./path-to-your-chart -f values.yaml

Replace ./path-to-your-chart with the path to your Helm chart.

Conclusion

Managing SSL certificates for Azure resources with custom domains can be challenging due to the frequent renewal requirements of Let's Encrypt certificates. This tool automates the entire process of certificate generation, validation, and deployment, significantly simplifying SSL certificate management for development and sandbox environments.

By running as a monthly cron job on AKS, it ensures that your certificates are always up-to-date without manual intervention. The integration with Azure Key Vault enhances security by providing centralized and secure storage of your certificates, which can be accessed by other Azure services as needed.

Leveraging Infrastructure as Code for Deployment

Once the certificates are stored in Azure Key Vault, you can further automate the deployment process by using infrastructure as code (IaC) tools like Pulumi or Terraform.
These tools can retrieve the certificates from Key Vault and deploy them to your Azure resources automatically.
By incorporating this into your IaC pipelines, you ensure that any updates to the certificates are seamlessly propagated to services like Azure API Management, Azure Front Door, or Azure Application Gateway, maintaining consistent and secure configurations across your infrastructure.

Key Benefits:

Automated Renewal: Eliminates the manual effort required to renew Let's Encrypt certificates every 90 days.
Cost Efficiency: Uses free Let's Encrypt certificates, reducing costs for non-production environments.
Scalability: Easily manages multiple domains and environments.
Security: Securely stores certificates in Azure Key Vault and restricts Cloudflare API access to your AKS cluster.

Give it a try and simplify your SSL certificate management process!

Resources:

GitHub Repository: az-keyvault-letsencrypt
Docker Image: baoduy2412/keyvault-letsencrypt

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[AKS] Implementing Cert Manager with Private Azure Kubernetes Service (AKS).

Steven Hoang — Mon, 18 May 2026 14:27:22 +0000

In a previous post, It detailed how to set up Cert Manager on a Raspberry Pi K3s Cluster. That was a great starting point, and in this article, I decided to explore a more complex scenario by deploying Cert Manager within a private Kubernetes cluster on Azure. I’m excited to share the insights and techniques I discovered along the way, hoping they can make your journey a bit smoother."

Azure Architecture Overview

The following diagram illustrates the architecture we'll be working with:

The setup involves two Virtual Networks (VNETs) that are peered:

CloudPC VNET: This is where we host all our Windows 365 Enterprise environments, allowing remote users to securely access the company’s resources.
AKS VNET: This VNET hosts our private AKS cluster. To keep things secure, I’ve set up a firewall that controls all outbound traffic, with no direct inbound access from the internet. The public IP is purely for outbound traffic—no inbound ports are left open.
NGINX Ingress: This piece allows CloudPC to access applications running on AKS through VNET peering, making sure everything stays within a private network.

The Challenge I Encountered: Securing Internal Traffic

One of the challenges I came across was figuring out how to secure the communication between the applications hosted on AKS and the CloudPC environment, even though it’s all internal within the virtual networks. I wanted to make sure that all data in transit was encrypted using SSL certificates.

How I Solved It: Leveraging Cloudflare DNS and Cert Manager

To address the challenge, I implemented the following approach:

Domain Setup with Cloudflare: Let’s assume I have a domain, drunk.dev, registered with Cloudflare. While this domain isn’t directly used for external-facing services. But, I utilize this domain with Let’s Encrypt to verify and issue SSL certificates for the ingress controllers of my applications within the AKS cluster.
Internal DNS Configuration on Azure: Internally, I created a private DNS Zone in Azure with the same name (drunk.dev) and linked this zone to both the CloudPC and AKS VNETs. This setup is critical as it ensures that internal DNS queries for the drunk.dev domain are resolved correctly within the private network, facilitating secure communication between services.

Installation

Create a Cloudflare DNS API Token: First, navigate to the Cloudflare profile and create an API token by following this link. The API token should have permissions to manage DNS records for the domains.

Additionally, for enhanced security, specify the AKS public IP address under Client IP Address Filtering in Cloudflare. This ensures that the API token is only accessible from the AKS platform, preventing unauthorized access from other locations.

Create a Kubernetes Secret for the Cloudflare API Token:

Next, create a Kubernetes secret to securely store the Cloudflare API token within the AKS cluster. This secret will be referenced by Cert Manager during DNS validation.

apiVersion: "v1"
kind: Secret
metadata:
  name: cf-dns-secret
stringData:
  token: "YOUR-CF-DNS-TOKEN"
# Replace 'YOUR-CF-DNS-TOKEN' with the actual API token generated in the previous step.

Cert Manager Installation:

Create a values.yaml file for Helm Installation: Before installing Cert Manager, create a values.yaml file with the following content. The extraArgs section is important as it directs Cert Manager to use Cloudflare’s DNS resolver for DNS-01 challenge validation.

# auto create CRD resources
installCRDs: true

# Default ingress value
ingressShim:
  defaultIssuerName: "letsencrypt-prod"
  defaultIssuerKind: "ClusterIssuer"
  defaultIssuerGroup: "cert-manager.io"

#extra args is important for Cloudflare DNS validation
extraArgs:
  - --dns01-recursive-nameservers-only
  - --dns01-recursive-nameservers=1.1.1.1:53

This configuration ensures that Cert Manager will only use Cloudflare’s DNS servers (specifically 1.1.1.1:53) to perform DNS-01 challenge validation, which is necessary for issuing SSL certificates.

Install Cert Manager with Helm: Now, proceed with installing Cert Manager using Helm. The following commands will add the Jetstack Helm repository, update it, and then install Cert Manager with the custom values.yaml configuration file above.

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --values values.yaml \
  -n cert-manager \
  --create-namespace --cleanup-on-fail

Set Up a ClusterIssuer for Cert Manager: The next step is create a ClusterIssuer resource to define how Cert Manager should obtain SSL certificates. The following template uses the Cloudflare DNS API token stored in the Kubernetes secret created earlier.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    # Replace with the administrator email associated with your domain.
    email: "admin@drunk.dev"
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - dns01:
          cloudflare:
            #Update this accoring to your domain
            email: "admin@drunk.dev"
            # Ensure that the name matches the secret you created (cf-dns-secret),
            # and the key references the correct data key within the secret (token).
            apiTokenSecretRef:
              name: cf-dns-secret
              key: token

Firewall Whitelisting

Since the AKS cluster’s outbound traffic is managed by a firewall, it’s neededs to whitelist specific external services to ensure that Cert Manager can successfully issue certificates. Without these exceptions, the certificate issuance process will fail.

Here’s what needs to allow in the Firewall rules:

Allow outbound access to api.cloudflare.com on port 443.
Allow outbound access to *.api.letsencrypt.org on port 443.

Nginx Ingress Installation

Setting up NGINX Ingress in a private AKS environment involves configuring it to use a private IP address and an internal ingress class.

Install NGINX Ingress Controller: To deploy NGINX as an internal Ingress controller with a private IP address, create a values.yaml file with the following configuration.

controller:
  hostNetwork: "false"
  useIngressClassOnly: "true"
  watchIngressWithoutClass: "true"
  # the ingress class name is internal
  ingressClass: "internal"
  # The custom ingress class
  ingressClassResource:
    name: "internal"
    enabled: true
    default: true
    controllerValue: k8s.io/ingress-nginx
  service:
    annotations:
      # This annotation to tell Azure to create an internal load balancer.
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    externalTrafficPolicy: "Local"
    # update this private IP address accroding to your address spaces.
    loadBalancerIP: "192.168.250.250"

Explanation:

hostNetwork: false ensures that the NGINX pods do not bind directly to the node’s network interfaces, maintaining isolation.
useIngressClassOnly: Ensures that only Ingress resources with the specified ingressClass will be processed by this controller.
ingressClass: Named internal to distinguish it from other Ingress classes, ensuring it’s used specifically for internal traffic.
service.annotations: The key annotation service.beta.kubernetes.io/azure-load-balancer-internal: 'true' tells Azure to create an internal load balancer instead of a public one.
loadBalancerIP: Assigns a static private IP address (192.168.250.250) to the NGINX load balancer, ensuring it’s accessible only within the internal network. Once NGINX is deployed with this configuration, it will only be accessible from within the internal network via the private IP address 192.168.250.250.

Install Nginx with Helm

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm nginx ingress-nginx/ingress-nginx \
  --values values.yaml \
  -n  nginx-ingress \
  --create-namespace --cleanup-on-fail

Configure DNS for Internal Access

After deploying the NGINX Ingress controller, the next step is to ensure that internal DNS queries resolve to the NGINX private IP. To do this, add an A record in the Azure private DNS zone that created earlier:

DNS Record: Add an A record pointing to 192.168.250.250 for the internal domain. This ensures that any internal traffic destined for blogs.drunk.dev is routed to the NGINX Ingress controller.

Create a Secure Ingress with Dynamic TLS Certificate Generation

Now, it’s time to create a secure Ingress resource that uses dynamic TLS certificate generation.

Here’s an example configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: drunk-blog-apps
  namespace: drunk-apps
  annotations:
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/backend-protocol: HTTP
    ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  # the name of ingress class percificly here.
  ingressClassName: internal
  # The tls config
  tls:
    - hosts:
        - blogs.drunk.dev
      secretName: tls-blogs-lets
  rules:
    # the host config
    - host: blogs.drunk.dev
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: blog-apps
                port:
                  number: 8080

Key Points:

ingressClassName: Specifies that this Ingress resource should be handled by the internal Ingress class, ensuring it’s routed through the private NGINX controller.
tls: Configures automatic TLS certificate generation for blogs.drunk.dev using Cert Manager. The certificate will be stored in a Kubernetes secret named tls-blogs-lets.
annotations: The force-ssl-redirect: 'true' annotation ensures that all HTTP traffic is redirected to HTTPS, securing the communication.

Once the Ingress resource is created, Cert Manager will automatically issue a TLS certificate for blogs.drunk.dev and bind it to the Ingress. The certificate will be monitored and automatically renewed by Cert Manager before expiration, ensuring continuous security without manual intervention.

Conclusion

So, that’s how I secured internal communications within my private AKS environment using Cert Manager and Cloudflare DNS management. This approach simplified the management of SSL certificates and provided an extra layer of security for internal data transmissions.

I hope you found this walkthrough helpful or at least interesting. If you have any thoughts, questions, or would like to share your own experiences, feel free to reach out. I’m always keen to hear how others are tackling similar challenges!

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[k8s] Step-By-Step Guide: Hosting Longhorn on K3s (ARM)

Steven Hoang — Mon, 18 May 2026 14:26:49 +0000

As you know by default the kubernetes provide a "local-path" storage. However, this local storage has many limitation:

Node Affinity: When using local-path storage, the volume created is tied to the specific node where the pod runs.
If that node goes down for maintenance or any other reason, the pods won’t be able to start on other nodes because they won’t find their volumes.
Not Network Storage: Local-path storage is not network-based. The volume remains local to the K3s node where the pod executes.
It doesn't allow data sharing across nodes.
Not Suitability for Production: While local-path storage is suitable for small, single-node development clusters,
it’s not recommended for production-grade multi-node clusters.

What is Longhorn?

Longhorn, an innovative open-source project by Rancher Labs, offers a reliable, lightweight, and user-friendly distributed block storage system for Kubernetes.

High Availability: Longhorn replicates storage volumes across multiple nodes in the Kubernetes cluster, ensuring that data remains available even if a node fails.
Cost-Effective: Traditional external storage arrays can be expensive and non-portable. Longhorn offers a cost-effective, cloud-native solution that can run anywhere.
Disaster Recovery: Longhorn allows you to easily create a disaster recovery volume in another Kubernetes cluster and fail over to it in the event of an emergency. This ensures that your applications can quickly recover with a defined Recovery Point Objective (RPO) and Recovery Time Objective (RTO).

Longhorn installation

Longhorn provides a straightforward method for installing the iSCSI driver and NFSv4 directly on all nodes. Follow the steps below to set up the necessary components.

Installing open-iscsi

The open-iscsi package is a prerequisite for Longhorn to create distributed volumes that can be shared across nodes.
Ensure that this driver is installed on all worker nodes within your cluster.

Execute the following command on your cluster to install the driver

# please check the latest release of the longhorn here https://github.com/longhorn/longhorn and update the version accordingly. Current version is v1.6.0
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.0/deploy/prerequisite/longhorn-iscsi-installation.yaml

After deploying the iSCSI driver, confirm the status of the installer pods using the following command:

kubectl get pod | grep longhorn-iscsi-installation

# The result
longhorn-iscsi-installation-pdbgq   1/1     Running   0          21m
longhorn-iscsi-installation-qplbb   1/1     Running   0          39m

Additionally, review the installation logs to ensure successful deployment:

kubectl logs longhorn-iscsi-installation-pdbgq -c iscsi-installation

# The result
...
IProcessing triggers for libc-bin (2.35-0ubuntu3.6) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for initramfs-tools (0.140ubuntu13.1) ...
update-initramfs: Generating /boot/initrd.img-6.5.0-18-generic
iscsi install successfully

Once the iscsi installed successfully, Then you can safely uninstall the above with following command.

kubectl delete -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.0/deploy/prerequisite/longhorn-iscsi-installation.yaml

Installing NFSv4 client

To enable Longhorn’s backup functionality and ensure proper operation, the NFSv4 client must be installed on the worker nodes within your cluster.

Follow these steps to set up the necessary components:

# please check the latest release of the longhorn here https://github.com/longhorn/longhorn and update the version accordingly. Current version is v1.6.0
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.0/deploy/prerequisite/longhorn-nfs-installation.yaml

After deploying the NFSv4 client, confirm the status of the installer pods using the following command:

kubectl get pod | grep longhorn-nfs-installation

# The results
NAME                                  READY   STATUS    RESTARTS   AGE
longhorn-nfs-installation-mt5p7   1/1     Running   0          143m
longhorn-nfs-installation-n6nnq   1/1     Running   0          143m

And also can check the log with the following command to see the installation result:

kubectl logs longhorn-nfs-installation-mt5p7 -c nfs-installation

# The results
...
rpc-svcgssd.service is a disabled or a static unit, not starting it.
rpc_pipefs.target is a disabled or a static unit, not starting it.
var-lib-nfs-rpc_pipefs.mount is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.6) ...
nfs install successfully

Once the NFSv4 installed successfully, Then you can safely uninstall the above with following command.

kubectl delete -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.0/deploy/prerequisite/longhorn-nfs-installation.yaml

Installing Longhorn

Preparing the configuration value.yaml file

csi:
  kubeletRootDir: "/var/lib/kubelet"
defaultSettings:
  diskType: "flesystem"

Install Longhorn in the longhorn-system namespace with configuration above.

# 1. added longhorn chart
helm repo add longhorn https://charts.longhorn.io
helm repo update

# 2. Installing
helm install longhorn longhorn/longhorn -f value.yaml --namespace longhorn-system --create-namespace

Once installed successfully and all the pods are up and running.
You should be able to access Longhorn UI through the longhorn-frontend service (needs port-forward or expose through nginx or cloudflare tunnel).

Uninstalling Longhorn

If any reason we would like to uninstall Longhorn helm then the below commands will help.

# Update `deleting-confirmation-flag` to allows uninstall longhorn
kubectl -n longhorn-system patch -p '{"value": "true"}' --type=merge lhs deleting-confirmation-flag
# Uninstall longhorn
helm uninstall longhorn -n longhorn-system
# Delete namespace
kubectl delete namespace longhorn-system

Using the Longhorn storage with Mariadb

To explore Longhorn storage capabilities, we’ll set up a MariaDB Galera multi-primary database cluster for synchronous replication and high availability. Follow these steps:

# Setup chart repo
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Install mariadb-ha
helm install mariadb-ha bitnami/mariadb-galera \
   --set global.storageClass=longhorn \
   --set rootUser.password=Pass@word1 \
   --set galera.mariabackup.password=Password1 \
   --set db.name=drunk_db \
   --namespace db --create-namespace

# Uninstall mariadb-ha
helm uninstall mariadb-ha -n db

After deployed successful, you should find three MariaDB pods running in the db namespace:

kubectl get pod -n db

# The results
NAME                          READY   STATUS    RESTARTS   AGE
mariadb-ha-mariadb-galera-0   1/1     Running   0          5m6s
mariadb-ha-mariadb-galera-1   1/1     Running   0          3m44s
mariadb-ha-mariadb-galera-2   1/1     Running   0          2m41s

You’ll also find three persistent volumes in the Longhorn UI portal. !Longhorn Volumes

Longhorn System Backup

Longhorn supports a variety of backup targets, including Azure Storage, AWS S3, Google Storage, NFS, and SMB/CIFS.
This post will initially cover the configuration for Azure Storage, with subsequent posts addressing the other backup targets.

System Backup with Azure Storage

This section assumes that you already have Azure Storage and a Kubernetes cluster that can connect to Azure.

Create a longhorn-azure-blob-backup.yaml secret with your Azure Storage Account credentials:

# Update the secret below with your Azure Storage Account credentials
apiVersion: v1
kind: Secret
metadata:
  name: longhorn-azure-blob-backup
  namespace: longhorn-system
stringData:
  AZBLOB_ACCOUNT_KEY: "YOUR_STORAGE_KEY"
  AZBLOB_ACCOUNT_NAME: "YOUR_STORAGE_NAME"

Apply the secret to the cluster using the following command.

kubectl apply -f longhorn-azure-blob-backup.yaml

Next, update the backup information in the defaultSettings section of the value.yaml file:

csi:
  kubeletRootDir: "/var/lib/kubelet"
defaultSettings:
  diskType: "flesystem"
  backupTargetCredentialSecret: "longhorn-azure-blob-backup" #The name of the secret created above.
  backupTarget: "azblob://YOUR_CONTAINER_NAME@core.windows.net/" # Trailer slash is important

Upgrade the Longhorn Helm chart with the updated values using the following command:

helm upgrade longhorn longhorn/longhorn -f value.yaml --namespace longhorn-system

# You should see a message indicating that the upgrade was successful
Release "longhorn" has been upgraded. Happy Helming!
NAME: longhorn
LAST DEPLOYED: Wed Feb 28 08:57:56 2024
NAMESPACE: longhorn-system
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
Longhorn is now installed on the cluster!

Please wait a few minutes for other Longhorn components such as CSI deployments, Engine Images, and Instance Managers to be initialized.

Visit our documentation at https://longhorn.io/docs/

Once the upgrade is complete, the backup information under Setting → General should reflect the changes made.
After creating a sys-backup under Setting → System Backup, you should see the following
You should be able to see the data being backed up into the Azure Storage Container.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[k8s] Step-By-Step Guide: Hosting Outline VPN on Kubernetes

Steven Hoang — Mon, 18 May 2026 14:26:16 +0000

In our previous article,
we were successfully installed NGINX on Kubernetes.Now, we're going to take NGINX for a spin and use it to host the Outline VPN on Kubernetes and open up our connection ports.

You're probably aware that by default, Outline VPN changes the client port each time a new connection is made.
It can be a bit of a challenge when we need to expose the ports through NGINX and get the outbound port on the whitelist at the firewall level.

However, there is a feature that allows us to modify the Outline VPN's default configuration during deployment.
With this little tweak, we can get all connections to pass through a single port and manage to expose both the management and client ports through NGINX.
Stick with us as we walk you through this process.

Install Outline VPN

Before proceeding with the installation of the Outline, it's essential to define some variables as follows:

Management Port (60000): This port facilitates the connection between the Outline Manager and the VPN server.
Client Port (40000): This port is assigned for client devices to establish a connection with the VPN server.
Hostname (vpn.drunkcoding.net): This DNS (Domain Name Server) allows client devices to communicate with the VPN server from the public internet.

Let's start with a new Outline-system namespace creation.

kubectl create namespace outline-system

Create a Self-sign certificate

To install Outline VPN, a required certificate plays multiple crucial roles:

Server Authentication: This certificate is key in verifying the VPN server you're connecting to is the genuine one.
Data Encryption: This certificate establishes the encryption for all data transmissions between your device and the VPN server.
If someone happens to intercept the data, they won't be able to decipher it due to this encryption.
Secured Connection Assurance: This essential certificate ensures the connection between the client devices and the VPN server is both private and secure.
This is particularly crucial when connecting from insecure networks like public Wi-Fi.

Let's generate a self-signed certificate.
It can be accomplished through various methods, each tailored to specific environments.

Here, we'll be using OpenSSL as an example. The commands illustrating this process are detailed below:

# 1. Create private key
openssl genrsa -out private.key 2048

# 2. Create a Certificate Signing Request (CSR) using the private key with some parameters as below:
#-----
# - Country Name (2 letter code) [AU]:VN
# - State or Province Name (full name) [Some-State]:VN
# - Locality Name (eg, city) []:HCM
# - Organization Name (eg, company) [Internet Widgits Pty Ltd]:drunkcoding
# - Organizational Unit Name (eg, section) []:DCN
# - Common Name (e.g. server FQDN or YOUR name) []:vpn.drunkcoding.net
# - Email Address []:system@drunkcoding.net

# - Please enter the following 'extra' attributes
# - to be sent with your certificate request
# - A challenge password []:123456
# - An optional company name []:DCN
openssl req -new -key private.key -out csr_request.csr

# 3. Create a self-signed certificate
openssl x509 -req -days 365 -in csr_request.csr -signkey private.key -out cert.crt

Once the certificate is generated, following command to import into kubernetes cluster.

kubectl create secret tls tls-outline-vpn-imported --cert=cert.crt --key=private.key --namespace=outline-system

Deploy Outline Service with following outline-deployment.yaml file.

PersistentVolumeClaim: A PersistentVolumeClaim named outline-vpn-claim is created which requests storage is being created in the namespace outline-system to store the configuration of Outline VPN.
Deployment: A Deployment named outline-vpn is being created in the namespace outline-system. With this Deployment, a Pod is created with a container that uses the image quay.io/outline/shadowbox:stable. The container defines two TCP ports (40000, 60000) to expose.
Service: A Service named outline-vpn is configured to expose the Pods and expose the ports (40000 and 60000) for both TCP and UDP protocols.

# 1. PersistentVolume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: outline-vpn-claim
  namespace: outline-system
status:
  phase: Bound
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 5Gi
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  #TODO: Remember to change `storageClassName` according to your environment.
  storageClassName: local-path
  volumeMode: Filesystem
---
#2. Pod Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: outline-vpn
  namespace: outline-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: outline-vpn
      name: outline-vpn
  template:
    metadata:
      labels:
        app: outline-vpn
        name: outline-vpn
    spec:
      volumes:
        - name: server-config-volume
          emptyDir: {}
        - name: shadowbox-config
          persistentVolumeClaim:
            claimName: outline-vpn-claim
        - name: tls
          secret:
            secretName: tls-outline-vpn-imported
            items:
              - key: tls.crt
                path: shadowbox.crt
              - key: tls.key
                path: shadowbox.key
            defaultMode: 420
      containers:
        - name: outline-vpn
          image: quay.io/outline/shadowbox:stable
          ports:
            - containerPort: 40000
              protocol: TCP
            - containerPort: 60000
              protocol: TCP
          env:
            - name: SB_API_PORT
              value: "60000"
            - name: SB_API_PREFIX
              value: b782eecb-bb9e-58be-614a-d5de1431d6b3
            - name: SB_CERTIFICATE_FILE
              value: /tmp/shadowbox.crt
            - name: SB_PRIVATE_KEY_FILE
              value: /tmp/shadowbox.key
          volumeMounts:
            - name: server-config-volume
              mountPath: /cache
            - name: shadowbox-config
              mountPath: /opt/outline
            - name: shadowbox-config
              mountPath: /root/shadowbox
            - name: tls
              readOnly: true
              mountPath: /tmp/shadowbox.crt
              subPath: shadowbox.crt
            - name: tls
              readOnly: true
              mountPath: /tmp/shadowbox.key
              subPath: shadowbox.key
          lifecycle:
            postStart:
              exec:
                command:
                  - /bin/sh
                  - "-c"
                  - >-
                    echo
                    '{"rollouts":[{"id":"single-port","enabled":true}],"portForNewAccessKeys":40000,"hostname":"vpn.drunkcoding.net"}'
                    >
                    /root/shadowbox/persisted-state/shadowbox_server_config.json;
          imagePullPolicy: Always
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
---
# 3. Service
apiVersion: v1
kind: Service
metadata:
  name: outline-vpn
  namespace: outline-system
  labels:
    app: outline-vpn
spec:
  ports:
    - name: apiport-tcp
      protocol: TCP
      port: 60000
      targetPort: 60000
    - name: apiport-udp
      protocol: UDP
      port: 60000
      targetPort: 60000
    - name: accessport-tcp
      protocol: TCP
      port: 40000
      targetPort: 40000
    - name: accessport-udp
      protocol: UDP
      port: 40000
      targetPort: 40000
  selector:
    app: outline-vpn
  type: ClusterIP
  internalTrafficPolicy: Cluster

Apply it on the cluster:

kubectl apply -f outline-deployment.yaml

Upon successful deployment, you should be able to see a pod along with its corresponding logs as in the screenshot below.

PostStart command & Environment variables explanation

In the deployment lifecycle configuration above, there is a postStart command
that creates a JSON file located at /root/shadowbox/persisted-state/shadowbox_server_config.json.

The structure of the JSON object should look like this:

{
  "rollouts": [
    {
      "id": "single-port",
      "enabled": true
    }
  ],
  "portForNewAccessKeys": 40000,
  "hostname": "vpn.drunkcoding.net"
}

Let's break down the components of the JSON configuration for the Outline VPN:

rollouts: This has an ID 'single-port', indicating to the Outline VPN that client connections are to be allowed on this single port.
portForNewAccessKeys: This represents the port number (40000), where new access keys will be created.
hostname: This refers to the domain name or IP address of the VPN server the clients will connect to, in this case being "vpn.drunkcoding.net".

There are also a few environment variables to acknowledge:

SB_API_PORT: It denotes the port exposed by the Outline Management API.
SB_API_PREFIX: It's a random GUID to be used as a prefix on the Outline Management API.
SB_CERTIFICATE_FILE: It points to a file, /tmp/shadowbox.crt, which corresponds to the certificate we created earlier.
SB_PRIVATE_KEY_FILE: This points to the path of the private key file. In this case, it's /tmp/shadowbox.key. This file matches the aforementioned certificate.

Exposing connection ports through nginx

Once we've completed the installation as mentioned above, our Outline Container will be active and providing services on ports 60000 and 40000.
Currently, this service is confined to the Kubernetes network, meaning they can't be accessed directly from external sources, such as the internet.

In order to make these services receptive to outside connections, we'll need to expose the ports through NGINX.
The following illustration provides a visual representation on how to do this.

To begin with, we need to update the values.yaml file from our previous NGINX deployment. This configuration will open up the needed ports.

Here's the template:

# Refer to line 155 and 160 here for details
# https://github.com/kubernetes/ingress-nginx/blob/main/charts/ingress-nginx/values.yaml

# 1. Expose the TCP with convention tcp: 'port':'namespace/service:port'
tcp:
  60000: "outline-system/outline-vpn:60000"
  40000: "outline-system/outline-vpn:40000"

# 2. Expose the UDP with convention udp: 'port':'namespace/service:port'
udp:
  40000: "outline-system/outline-vpn:40000"

controller:
  service:
    loadBalancerIP: "192.168.1.85"

After updating the values.yaml with the correct information, re-upgrade the helm chart using the command:

# 1. To install brand new nginx
helm install nginx ingress-nginx/ingress-nginx --values values.yaml -n nginx-ingress

# 2. To update the existing nginx
helm upgrade nginx ingress-nginx/ingress-nginx --values values.yaml -n nginx-ingress

# 3. TO delete existing nginx and re-install with step 1 above.
helm delete nginx -n nginx-ingress

Managing the Outline VPN

Follow these steps to manage your Outline VPN:

Step 1: Download the Outline Manager

Download the Outline Manager from Outline's official website.

Step 2: Prepare the Connection Configuration

Prepare the connection configuration with the following parameters:

apiUrl: Use the following format https://{hostname}:{management-port}/{SB_API_PREFIX}.
certSha256: This is the thumbprint of the certificate created. Use the following command to access the thumbprint:

echo SHA=$(openssl x509 -noout -fingerprint -sha256 -inform pem -in cert.crt | sed "s/://g" | sed 's/.*=//')

Step 3: Generate the Configuration

Our configuration should look like this:

{
  "apiUrl": "https://vpn.drunkcoding.net:60000/b782eecb-bb9e-58be-614a-d5de1431d6b3",
  "certSha256": "34B3C8EB1C6EC9B5335556D7E8DC73A30152D27C66B054BAB8ACF5D11AE0C810"
}

Step 4: Setup Outline Anywhere

Open the Outline Manager App and click Setup Outline Anywhere. Paste the configuration into the second input box and click Done. .

Step 5: Connect to the Outline VPN Server

On successful configuration, you should be able to connect to the Outline VPN server as shown below:

Step 6: Create a Connection

To allow the clients to connect to the server, click Add new key to create a connection and note down the access key:

ss://Y2hhY2hhMjAtaWV0Zi1wb2x5MTMwNTpQc1YxY0V0ZkhzSVFueEJFVEVsMFRF@vpn.drunkcoding.net:40000/?outline=1

Getting Started with the Outline Client

To get started with the VPN, follow the steps below:

Begin by navigating to the Outline official website to download the client application. Be sure to select the version compatible with your platform architecture.
Launch the client application. Select Add Access Key, then input the access key mentioned above. Afterward, click on Add Server.
Proceed by clicking on the 'Connect' button to establish a connection.
To verify the VPN server's capability, access myip.info. Upon successful connection, your public IP address should reflect the Kubernetes outbound public IP. This means the VPN server is functioning as expected.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[k8s] Step-By-Step Guide: Nginx Alternative with Cloudflare Tunnel, Enables services to internet a public static IP address

Steven Hoang — Mon, 18 May 2026 14:25:42 +0000

In the previous articles we successfully:

However, to expose our services to the internet, it's essential to obtain a Static Public IP Address and configure the router/firewall to open ports 80 and 443.
If for any reason we're unable to meet these requirements, we won't be able to expose our services online.

In addition, if our organization relies on private Kubernetes on cloud platforms such as AKS, EKS, or GKS, and we wish to expose a select set of services to the internet
without jeopardizing security, we might consider using Cloudflare Tunnel.

Let's delve into this topic further.

Cloudflare Tunnel Configuration

This guide assumes that we have followed the instructions from our previous post, and configured Cloudflare account with at least one onboarded domain.
The next step is to create a Cloudflare Zero Trust Account. While creating this account might require adding a payment method, please note that there are no charges for the first 50 users. You can proceed to register without any hesitation.

Once logged in, navigate to Access => Tunnel and create a new tunnel. For the purposes of this guide, we'll name it pi-k3s. After creating the tunnel, make sure to copy the tunnel token that appears (similar to the one below):

eyJhIjoiYWVlMGFjYzZiYejTkz....yzCfgm7oqfnhz2DrJDKyL8PBDr9hR5FvYgDR45TxPiAxbmVW=

Finally, ensure we click the Save button to confirm the creation of the tunnel.

Kubernetes Tunnel Installation

Create cloudflare Namespace. It's a good practice to install the tunnel in its own namespace. Use this command:

kubectl create namespace cloudflare

Create the cloudflare-tunnel.yaml deployment file as below:

apiVersion: v1
kind: Secret
metadata:
  name: cloudflare-tunnel
  namespace: cloudflare
  labels:
    app: cloudflare-tunnel
type: Opaque
stringData:
  # the cloudflare tunnel token here
  token: 'eyJhIjoiYWVlMGFjYzZiYejTkz....yzCfgm7oqfnhz2DrJDKyL8PBDr9hR5FvYgDR45TxPiAxbmVW='
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloudflare-tunnel
  namespace: cloudflare
  labels:
    app: tunnel
spec:
  replicas: 2
  selector:
    matchLabels:
      app: cloudflare-tunnel
  template:
    metadata:
      labels:
        app: cloudflare-tunnel
    spec:
      containers:
        - name: cloudflare-tunnel
          image: cloudflare/cloudflared:latest
          args:
            - tunnel
            - '--no-autoupdate'
            - run
            - '--token'
            - $(token)
          envFrom:
            - secretRef:
                name: cloudflare-tunnel
          resources:
            limits:
              cpu: 500m
              memory: 512Mi
            requests:
              cpu: 1m
              memory: 10Mi
          imagePullPolicy: Always
          securityContext:
            readOnlyRootFilesystem: true
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
      automountServiceAccountToken: false
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 1
  progressDeadlineSeconds: 600

Install Cloudflare tunnel:

kubectl apply -f cloudflare-tunnel.yaml

Verify running pods after deployed.

Back to the Cloudflare Zero Trust the tunnel status should be in Health also.

Exposing the Application to the Internet

Navigate to the tunnel configuration page. Under the 'Public Host' section, add a public host name to expose our echo service to the internet. See the example below.

Note: Kubernetes internal service URLs follow the convention: http://{service-name}.{namespace}.svc.cluster.local.

Verify the performance of the application by visiting https://echo.drunkcoding.net. The service should be accessible without any constraints.
I have established two endpoints as follows and conducted a load test using Postman.
The results were astonishing as the Cloudflare tunnel delivered speeds even greater than direct access via Nginx.

echo-nginx.drunkcoding.net: This endpoint provides access to the echo application through Nginx ingress and with a public IP address.
echo.drunkcoding.net: This endpoint offers access to the echo application through the Cloudflare tunnel.

Please see the results in the attached image.

Note: The cluster hosting this application is based in Singapore, while the test was conducted from a terminal in Vietnam.

Concluding Remarks

Leveraging Cloudflare tunnels simplifies application exposure to the internet without the necessity of below:

A public IP Address.
Port forwarding.
Firewall whitelisting.
Nginx proxy/ingress.
A Cert-manager or Cloudflare origin server certificate.

This results in a significantly simplified infrastructure setup.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[k8s] Step-By-Step Guide: Cert-Manager Alternative with Cloudflare, Implementing Free SSL Certificates for Kubernetes Clusters

Steven Hoang — Mon, 18 May 2026 14:25:09 +0000

In our previous post, we walked through the process of successfully installing Cert-Manager to handle SSL certificate assignments for all ingresses.
While advantageous, this approach comes with a few noteworthy challenges:

Limited validity period: Certificates provided by Cert-Manager are valid for a short period (90 days), meaning any third-party systems utilizing the services may need to update their certificate whitelist every 90 days.
Inappropriate for production environments: Certificates provided by Let's Encrypt, while useful, may not be suitable for production environments.
Opening Port 80: To validate and issue the certificate, Cert-Manager requires the use of insecure HTTP on port 80 during the process. However, if for any reason, the infrastructure team is reluctant to expose port 80 to the internet, then the operation of Cert-Manager may be compromised.
Potential Cert-Manager failures: There can be instances where Cert-Manager encounters issues and fails to renew the certificate. In such cases, third-party systems may be unable to access our service due to failed certificate verification.

By understanding these issues, We'll explore a better solution to replace the Cert-Manager with Cloudflare. More detailed information will follow in subsequent posts.

Cert-Manager Alternative

Cloudflare provides several valuable services:

Domain Management: Makes it simple to purchase, move, and control domain names. It centralised DNS record setup, subdomain management in once place.
Universal SSL (Free): Provides automatic secure HTTPS access to our website. This saves time from the need to buy and manage SSL certificates.
Advanced Certificate Manager: Perfect for businesses wanting more control over their SSL certificates. We can customize the certificates, including those for multiple subdomain levels.
Proxy: Sits between the website's server and its visitors, with WAF enabled through proxy giving protection from threats like DDoS attacks and bots, while also enhancing performance.
All requests appear to be coming from Cloudflare IP addresses, enabling us to enhance site security by just whitelisting Cloudflare IP Addresses.

Kickstart with Cloudflare

Before we get started, ensure that we have a Cloudflare account that can register for one, free of charge, here.
The next essential step is to onboard a Domain into Cloudflare's management system. Rest assured, this process is straightforward and involves zero downtime.
For demonstration, I have onboarded my drunkcoding.net to Cloudflare. Once a Domain is onboarded, it should resemble the following demonstration.
Moving forward to the DNS Records management, I have added an A record with the proxy option enabled, as shown below.

Once set up, all requests to subdomains such as echo.drunkcoding.net, wiki.drunkcoding.net, etc., will be redirected to my public IP address.
Next, under SSL/TLS, I created an Origin Server for the domains drunkcoding.net and *.drunkcoding.net and chose the certificate validity from 7 days to 15 years.

After setting this up, please ensure to download the certificate and private key immediately and save it to local files as we won't be able to access the private key in the future.
Following this, download the Cloudflare Root CA certificate from here.
Once all the above steps are complete, we should have the following three files:

cert.crt: This public key certification is in PEM format.
private.key: This private key of the certificate is also in PEM format.
Root CA: This root CA certificate is also in PEM format.

Switch the SSL/TLS encryption mode of the domain to Full (strict)

Cloudflare Certificate Installation

Certificate preparation:

Before to proceeding, it is necessary to append the contents of the Root CA file to the cert.crt file, as illustrated in the following example:

-----BEGIN CERTIFICATE-----
    Content of cert.crt file here
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
    Content of ca file here
-----END CERTIFICATE-----

Create a secret certificate on kubernetes:

Update the name based on your naming convention. In this context, we're using tls as the prefix and import as the suffix.
This denotes that it's a TLS certificate secret imported from a third party, as opposed to being auto-generated by Cert-Manager.

kubectl create secret tls tls-drunkcoding-net-import --cert=cert.crt --key=private.key --namespace=our-namespace

Remember to do this for each namespace in the cluster if there are services utilizing this domain.

After the successful creation, a secret, similar to the one illustrated below, should be identifiable.

Update Application Ingress:

Leverage the existing echo-app ingress. We'll revise the ingress configuration use the imported certificate by change the secretName of the ingress as below.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  namespace: default
  annotations:
    kubernetes.io/tls-acme: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - echo.drunkcoding.net
      # only need to change this secret name.
      secretName: tls-drunkcoding-net-imported
  rules:
    - host: echo.drunkcoding.net
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo-service
                port:
                  number: 80

The application will be protected with cloudflare cert, and below is the detailed certificate information as seen from the browser.

You may observe that the certificates provided by Cloudflare and Cert-Manager bear a resemblance, owing to their shared use of Let's Encrypt for free SSL certificate generation.
However, it's important to note that for production applications, an upgrade to Cloudflare Advanced Certificate Manager
is recommended for Production environment which provides a certificate from a standard, trusted third-party authority and boasts an extended validity period.

After completing these steps, we can proceed with uninstalling the Cert-Manager, as it is no longer needed.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[k8s] Step-By-Step Guide: Installation of Cert-Manager, Implementing Free SSL Certificates for Kubernetes Clusters

Steven Hoang — Mon, 18 May 2026 14:24:36 +0000

Welcome back to our ongoing dialogue about Kubernetes. In the previous article, we successfully executed the Nginx installation and made our applications internet-accessible.
However, you might've observed that the applications are operating under the HTTP protocol, which is not secure at present.

As of July 2018, with the release of Chrome 68, Google started marking all non-HTTPS websites as 'Not secure' in the Chrome browser.
This means that if a website doesn't use HTTPS, Chrome displays a warning to users in the address bar, indicating that the connection is not secure.
The goal of this move was to push more webmasters to secure their websites with SSL/TLS certificates, providing a safer browsing experience for users.

Securing our applications through SSL encryption is crucial, particularly in production environments. For enhanced security, it's recommended to procure and implement valid SSL certificates for all production applications.

However, for the development or testing environments, which may not require paid SSL certificates, you can make use of Cert-Manager.
This tool utilizes Let's Encrypt to generate SSL certificates free of cost, providing a secure and cost-effective solution for non-production environments.

Cert-Manager installation

Prerequisite - Kubernetes cluster with admin access is required. Make sure you have kubectl installed and configured to interact with your cluster.
Add the Jetstack Helm repository - Jetstack is the organization that maintains cert-manager, and they provide a Helm repository that we can use to install it:

helm repo add jetstack https://charts.jetstack.io
helm repo update

Install cert-manager CustomResourceDefinitions (CRDs) - These are the resources that cert-manager uses to store its configuration. Run the following command to install the CRDs:

Please make certain that you are utilizing the most up-to-date version. You can achieve this by substituting v1.13.0 with the newest release from the cert-manager official GitHub repository.
Visit the following link to obtain the latest version: Cert-Manager Releases.

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.crds.yaml

Create cert-manager Namespace - It's a good practice to install cert-manager in its own namespace. Use this command:

kubectl create namespace cert-manager

Create value.yaml file with the content below

ingressShim:
  defaultIssuerName: "letsencrypt-prod"
  defaultIssuerKind: "ClusterIssuer"

Install cert-manager Helm chart - This will install cert-manager along with its components:

helm install cert-manager jetstack/cert-manager --values values.yaml -n cert-manager

Verify the Installation - Check if the cert-manager pods are running:

Cluster Issuer configuration

# File name is `cluster-issuer.yaml`
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  # The name should be the same with `defaultIssuerName` above
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    # Replace with your domain email.
    email: support@drunkcoding.net
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          ingress:
            # The ingress class name of nginx.
            class: nginx

Apply it on the cluster:

kubectl apply -f cluster-issuer.yaml

Update echo-app ingress.

Leverage the existing echo-app to enhance your project. We'll revise the ingress configuration to enable HTTPS for secure communication in our application.
Additionally, we'll integrate with cert-manager for automated SSL certificate generation.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  namespace: default
  annotations:
    # 1. enable cert-manager for this ingress
    kubernetes.io/tls-acme: "true"
spec:
  ingressClassName: nginx
  # 3. Config the tls secret name. Replace the domain and secretName below with your config accordingly.
  tls:
    - hosts:
        - echo.drunkcoding.net
      secretName: tls-drunkcoding-net
  rules:
    - host: echo.drunkcoding.net
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo-service
                port:
                  number: 80

The certificate generated from Let's Encrypt has validity of 90 days. However, the cert-manager will automatically renew the certificate as it nears its expiration date.

Verify application

Once the configuration is properly set up and the certificate has been successfully issued, you should be able to locate a certificate named tls-drunkcoding-net housed under the default namespace secrets.

The application is also fully functional with SSL for secure communication.

Below is the detailed certificate information as seen from the browser.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

[k8s] Step-By-Step Guide: Installing Nginx Ingress on K3s Pi 4 Cluster

Steven Hoang — Mon, 18 May 2026 14:24:03 +0000

In our previous article, we successfully set up a k3s Pi cluster. We will now build upon that foundation. Let's dive in!

pi-master: 192.168.1.85 (Running Pi OS Lite 64Bit)
pi-node-1: 192.168.1.86 (Running Pi OS Lite 64Bit)
pi-node-2: 192.168.1.87 (Running Pi OS Lite 64Bit)

Router Port Forwarding Setup.

In order to make the internal applications accessible via the internet, we need to set up port forwarding on our router.
This routing process will redirect internet requests coming to ports 80 and 443 to our master private IP node (192.168.1.85).

Please note, the configuration interface may vary among different routers. Nonetheless, most broadband routers should offer the same functionality pertaining to port forwarding.

Here are my current router settings.

Nginx installation

We're going to start by installing Nginx on our cluster. In the following guide, we will illustrate how to set up and run Nginx on K3s.
At its core, Nginx will listen to inbound requests on the master node's IP address and subsequently forward these requests to the services operating within our cluster.

1. Config Ip address

Helm charts come with a file called values.yaml which contains the default configuration values.
We can override these values by creating your own values.yaml file. Here is an example:

# Refer to line 434 here for details
# https://github.com/kubernetes/ingress-nginx/blob/main/charts/ingress-nginx/values.yaml

controller:
  service:
    # Our primary node ip address here.
    # Do remember replacing this ip address with your once accordingly.
    loadBalancerIP: "192.168.1.85"

2. Download the Helm chart:

Download the Nginix helm chart. You can do this by adding the Nginx repo to the Helm. Run the following commands:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

3. Create namespace

kubectl create namespace nginx-ingress

4. Install the Helm chart:

Now you can install the Helm chart using your custom values.yaml file to override the default configuration values. Run the following command:

helm install nginx ingress-nginx/ingress-nginx --values values.yaml -n nginx-ingress

5. Verify nginx pod:

After installed successfully, we should be able to find a pod running there:

Nginx Verification

1. Deploy the echo application:

You can deploy an echo server application using a simple Kubernetes deployment and service.
The echo server will respond with the same request it receives.

Here is a sample YAML file you can use:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deployment
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - name: echo
          image: ealen/echo-server
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: echo-service
  namespace: default
spec:
  ports:
    - port: 80
  selector:
    app: echo

Save this YAML into a file, let's say echo-app.yaml, and apply it to default namespace (using default namespace in Production is not recommended):

kubectl apply -f echo-app.yaml -n default

Create an ingress rule:

Now that your echo server is running, you can create an ingress rule to route traffic to it.

Here is a sample ingress YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  namespace: default
spec:
  ingressClassName: nginx
  rules:
    # Replace the domain below with your domain accordingly.
    - host: echo.drunkcoding.net
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo-service
                port:
                  number: 80

3. Update your domain DNS

To ensure you can access from the internet, you need to point a domain to your public address.

Here is my drunkcoding.net DNS configuration on Cloudflare for reference purposes.

After all these configurations now we should be able to access your application hosting on our k3s cluster from the internet.
When accessing to http://echo.drunkcoding.net you able to see the JSON response from the echo pod as below.

Thank You

Thank you for taking the time to read this guide! I hope it has been helpful, feel free to explore further, and happy coding! 🌟✨

Steven | GitHub

Forem: Steven Hoang

[Tools] Drunk Charts: A Reusable Helm Library for Kubernetes Deployments

Introduction

Table of Contents

Architecture

drunk-lib: The Library Chart

Available Templates

Helper Functions

How Templates Work

Deployment Template — Full Schema

StatefulSet Template

Security Defaults

Using drunk-lib in Your Own Charts

drunk-app: The Application Chart

Installation

Minimal Deployment

Environment Variables and Secrets

Health Checks and Autoscaling

Azure Key Vault Integration (CSI Driver)

TLS Secrets Management

Gateway API with TLS Validation

CronJobs and Jobs

Network Policies

Init Containers

Claude Code AI Plugins

Installing the Plugins

drunk-app Plugin

drunk-lib Plugin

Why a Library Chart?

OCI Distribution

Conclusion

[DevOps] Automating Branch Cleanup in Azure DevOps with Node.js

Introduction

Table of Contents

Why Automate Branch Cleanup?

Prerequisites

Project Setup

Configuration File

Implementing the TypeScript Script

1. Loading Environment Variables

2. Defining the Configuration Interface

3. Setting Constants

4. Getting the Git API Client

5. Loading the Configuration

6. Retrieving Repositories and Branches

7. Determining the Last Commit Date

8. Checking if a Branch is Merged

9. Deleting a Branch

10. Compiling the Exclusion List

11. Cleaning Up Branches

Automating with Azure DevOps Pipeline

Conclusion

Additional Resources

Thank You

[Tools] Cleaning Up Azure Service Bus Dead-Letter Queues with .NET

Introduction

Table of Contents

Understanding Dead-Letter Queues

Why Regularly Clean Up Dead-Letter Messages?

1. Prevent Storage Overruns

2. Maintain System Performance and Reliability

3. Enable Effective Error Handling and Analysis

Implementing a Dead-Letter Cleanup Service with .NET

Prerequisites

Getting the Source Code

Service Configuration

How the Cleanup Service Works

Archiving Structure in Blob Storage

Setting Up the Service

Option 1: Running Locally

Option 2: Using Docker

Running with Docker Compose

Running with Docker Command Line

Managing Storage Costs with Lifecycle Policies

Conclusion

Additional Resources

Thank You

[AZ] How to Scan and Disable Inactive Accounts on Azure EntraID

Introduction

Table of Contents