To solve this problem, I implemented a Jenkins Configuration as Code (JCasC) approach, allowing me to deploy a fully configured Jenkins instance on Kubernetes using a custom Docker image, ConfigMaps, Kubernetes Secrets, and Job DSL.

The goal was simple: make Jenkins configuration reproducible, version-controlled, and easy to restore without manual intervention.

Building a custom Jenkins image with preinstalled plugins

The first step was to create a custom Jenkins Docker image based on the official Jenkins distribution with JDK 21.

Instead of installing plugins manually through the Jenkins UI, I embedded all required plugins directly into the image during the build process.

FROM docker.io/jenkins/jenkins:jdk21
USER root
ENV CASC_JENKINS_CONFIG=/var/jenkins/casc_config
RUN apt-get update && apt-get install -y \
    lsb-release curl ca-certificates
RUN curl -fsSLo /usr/share/keyrings/docker-archive-keyring.asc \
    https://download.docker.com/linux/debian/gpg
RUN echo "deb [arch=$(dpkg --print-architecture) \
    signed-by=/usr/share/keyrings/docker-archive-keyring.asc] \
    https://download.docker.com/linux/debian \
    $(lsb_release -cs) stable" \
    > /etc/apt/sources.list.d/docker.list
RUN apt-get update && apt-get install -y docker-ce-cli
USER jenkins
RUN jenkins-plugin-cli --plugins
    "configuration-as-code job-dsl git workflow-job workflow-cps saml oic-auth matrix-auth gitea docker-plugin docker-commons docker-java-api"

The most important plugins in this setup are: * Configuration as Code: Automatically configures Jenkins using YAML files. * Job DSL: Defines and creates Jenkins jobs programmatically. * OpenID Connect Authentication: Integrates Jenkins with an external identity provider such as Keycloak. * Matrix Authorization Strategy: Controls permissions for users and groups. * Docker Plugin: Provides dynamically provisioned Jenkins build agents. I also installed the Docker CLI to support Docker-related operations. The Docker plugin itself communicates with a compatible Docker API endpoint.

By building plugins into the image, I can ensure that every deployment starts with a consistent set of dependencies. For stronger reproducibility, I would pin the Jenkins base image and plugin versions rather than relying on moving tags and latest compatible versions.

Configuring Jenkins with Configuration as Code

After preparing the image, I used the Configuration as Code plugin to manage Jenkins settings through YAML.

The environment variable:

CASC_JENKINS_CONFIG=/var/jenkins/casc_config

tells Jenkins where to find its configuration files.

Here is a simplified example based on my implementation:

jenkins:
  numExecutors: 2
  mode: NORMAL

  authorizationStrategy:
    globalMatrix:
      entries:
        - group:
            name: "admin"
            permissions:
              - "Overall/Administer"
        - group:
            name: "authenticated"
            permissions:
              - "Overall/Read"
              - "Job/Read"
              - "Job/Build"

  securityRealm:
    oic:
      clientId: "jenkins-oic-auth"
      clientSecret: "${OIDC_CLIENT_SECRET}"
      userNameField: "preferred_username"
      groupsFieldName: "groups"
      serverConfiguration:
        manual:
          issuer: "https://keycloak.example.com/realms/master"
          scopes: "openid email profile"

  clouds:
    - docker:
        name: "podman"
        containerCap: 3
        dockerApi:
          dockerHost:
            uri: "unix:///var/run/docker.sock"
        templates:
          - labelString: "alpine-jdk21"
            name: "alpine-jdk21"
            dockerTemplateBase:
              image: "jenkins/inbound-agent:latest-alpine-jdk21"
            remoteFs: "/home/jenkins/agent"
            mode: EXCLUSIVE
            connector:
              jnlp:
                jenkinsUrl: "https://jenkins.example.com/"
                user: "1000"
jobs:
  - script: >
      pipelineJob('Terraform_AWS_account') {
        definition {
          cpsScm {
            lightweight(true)
            scm {
              git {
                remote {
                  url('ssh://git@git.example.com:7999/infra/project.git')
                  credentials('nutcracker-rsa-key')
                }
                branches('*/main')
              }
            }
            scriptPath('path/to/Jenkinsfile')
          }
        }
      }

In my setup, I integrated Jenkins with Keycloak using OpenID Connect, configured role-based permissions through matrix authorisation, and defined Docker-based build agents.

The agent configuration uses a Docker-compatible API endpoint, which can also be provided by Podman. The socket must be available to the Jenkins controller and accessible with appropriate permissions. On Kubernetes, I would avoid mounting a privileged host Docker socket where possible and prefer a dedicated agent provisioning mechanism.

Managing credentials securely with Kubernetes Secrets

One important consideration is handling sensitive information.

Although JCasC supports defining credentials directly in YAML, storing private keys or authentication secrets in a ConfigMap or Git repository is not a secure solution.

Instead, I can store sensitive data in Kubernetes Secrets and reference them from the JCasC configuration.

For example, the SSH credential definition becomes:

credentials:
  system:
    domainCredentials:
      - credentials:
          - basicSSHUserPrivateKey:
              scope: GLOBAL
              id: "nutcracker-rsa-key"
              username: "rsa-key"
              description: "rsa key for Git access"
              privateKeySource:
                directEntry:
                  privateKey: "${JENKINS_RSA_PRIVATE_KEY}"

The ${JENKINSRSAPRIVATE_KEY} expression is resolved by the Configuration as Code plugin from an environment variable.

Now can create the Kubernetes Secrets using an existing SSH private key and OIDC taken secret taken from Keycloak:

kubectl create secret generic jenkins-secrets --namespace jenkins --from-file=rsa-private-key=./id_rsa --from-literal=oidc-client-secret='YOUR_OIDC_SECRET'

The Job DSL configuration is included in the same JCasC YAML file:

jobs:
  - script: >
      pipelineJob('Terraform_AWS_account') {
        definition {
          cpsScm {
            lightweight(true)
            scm {
              git {
                remote {
                  url('ssh://git@git.example.com:7999/infra/project.git')
                  credentials('nutcracker-rsa-key')
                }
                branches('*/main')
              }
            }
            scriptPath('path/to/Jenkinsfile')
          }
        }
      }

This configuration automatically creates a pipeline named TerraformAWSaccount and connects it to a Git repository containing the Jenkinsfile.

The SSH credential is referenced by its Jenkins credential ID, so the private key does not need to appear in the Job DSL script.

This approach allows me to version-control not only Jenkins system settings but also the pipeline definitions themselves.

Finally, I defined a Kubernetes Deployment that mounts the ConfigMap into the path specified by CASCJENKINSCONFIG

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jenkins
  namespace: jenkins
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: jenkins
  template:
    metadata:
      labels:
        app: jenkins
    spec:
      containers:
        - name: jenkins
          image: registry.example.com/jenkins:1.0.0

          ports:
            - containerPort: 8080
            - containerPort: 50000

          env:
            - name: CASC_JENKINS_CONFIG
              value: /var/jenkins/casc_config

            - name: JENKINS_RSA_PRIVATE_KEY
              valueFrom:
                secretKeyRef:
                  name: jenkins-secrets
                  key: rsa-private-key

            - name: OIDC_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: jenkins-secrets
                  key: oidc-client-secret

          volumeMounts:
            - name: jenkins-casc
              mountPath: /var/jenkins/casc_config
              readOnly: true

            - name: jenkins-home
              mountPath: /var/jenkins_home

      volumes:
        - name: jenkins-casc
          configMap:
            name: jenkins-casc

        - name: jenkins-home
          persistentVolumeClaim:
            claimName: jenkins-home

In this deployment: * The custom image contains all required Jenkins plugins. * The ConfigMap provides the JCasC YAML configuration. * Kubernetes Secrets provide sensitive credentials through environment variables. * A PersistentVolumeClaim stores Jenkins runtime data, build history, and other persistent state. The PVC must be created separately. This example also assumes that Jenkins agents are configured independently or that the Docker-compatible endpoint defined in JCasC is available to the controller.

An important detail is that updating the ConfigMap does not automatically restart Jenkins or guarantee that the new configuration is applied. In my deployment process, I can trigger a rollout restart:

kubectl rollout restart deployment/jenkins -n jenkins

Jenkins then loads the configuration from the mounted YAML file during startup.

Benefits of this approach

By combining Kubernetes, a custom Jenkins image, JCasC, and Job DSL, I achieved a deployment model where most of the Jenkins configuration is defined declarativelyt.

The main benefits are reproducibility, simplified disaster recovery, version-controlled configuration, and reduced manual administration.

It also makes upgrading Jenkins easier: I can build a new image with updated plugins, validate the configuration in a test environment, and deploy the updated version through Kubernetes.

The most important improvement is that Jenkins is no longer configured primarily through its UI. Instead, its configuration becomes part of the infrastructure code, making changes easier to review, track, and reproduce.

This is really cheap and easy to work with For around $3, you can buy an ESP board with a built-in relay, such as the ESP Relay 1.0 shown in the picture below.

The relay allows you to open or close an electrical circuit, which essentially means you can turn on, turn off, or power-cycle almost any AC-powered device .I power the ESP Relay board using a small 3V power adapter from an old Nokia phone. It's a simple and inexpensive way to reuse an old charger instead of buying a dedicated power supply.

I probably don't need to explain how many things we can control using just our smartphones. :)

The code below, uploaded to the ESP controller using Arduino IDE, starts a simple HTTP server that allows you to switch the relay on or off directly from your web browser.

In my case, I've found two particularly useful applications:

• Remotely rebooting my ISP's router, which is located in a hard-to-reach spot in the attic.
• Automatically turning on my drip coffee maker at 6 AM using a simple curl command scheduled via cron impressed my wife. :D

#include<ESP8266WiFi.h> 

const char* ssid = "MyHomeWiFiSSID"; //your WiFi Name
const char* password = "WiFiPassword";  //Your Wifi Password
int ledPin = 03; 
WiFiServer server(80);
void setup() {
  Serial.begin(115200);
  delay(10); 
  pinMode(ledPin, OUTPUT);
  digitalWrite(ledPin, LOW); 
  Serial.println();
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid); 
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("");
  Serial.println("WiFi connected"); 
  server.begin();
  Serial.println("Server started");
  Serial.print("Use this URL to connect: ");
  Serial.print("http://");
  Serial.print(WiFi.localIP());
  Serial.println("/"); 
}

void loop() {
  WiFiClient client = server.available();
  if (!client) {
    return;
  }
  Serial.println("new client");
  while(!client.available()){
    delay(1);
  } 
  String request = client.readStringUntil('\r');
  Serial.println(request);
  client.flush(); 
  int value = LOW;
  if (request.indexOf("/LED=ON") != -1)  {
    digitalWrite(ledPin, HIGH);
    value = HIGH;
  }
  if (request.indexOf("/LED=OFF") != -1)  {
    digitalWrite(ledPin, LOW);
    value = LOW;
  }
  client.println("HTTP/1.1 200 OK");
  client.println("Content-Type: text/html");
  client.println(""); 
  client.println("");
  client.println("");
  client.print("Led is : "); 
  if(value == HIGH) {
    client.print("On");
  } else {
    client.print("Off");
  }  client.println("");  
client.println(" On ");
   client.println(" Off ");  
  client.println(" ");
     delay(1);
   Serial.println("Client disonnected");
  Serial.println("");   }
//code copied from link

Keep in mind: Exposing an unauthenticated HTTP endpoint that controls electrical equipment to the public internet is a bad idea. Keep it on a trusted local network or access it through a VPN. And second thing

A relay ESP-01S is marked 10A/250V AC is not necessarily suitable for every 10A load. Motors, transformers, and other inductive loads can generate high inrush currents and voltage spikes.

//use random_word::Lang;
use std::io::{self, Write};
use std::process::ExitCode;
use serde::Deserialize;

fn guess_word(s: &str) {
    let mut chance : i8 = 6;
    let mut ch : char = ' ';
    println!("The word has {} letters.", s.chars().count());
    let mut char_array: Vec<char> = vec!['_'; s.chars().count()];
    loop {
            println!("--- Hangman game ---");
            println!("Guess the word! You have 6 tries to win the game.");
            println!("Enter your letter that might me in the word (A-Z): ");

            println!("Currently word looks like this:");
            char_array.iter().for_each(|c| print!(" {} ", c));

            println!("\n");
            let mut input = String::new();
            io::stdin().read_line(&mut input);

            let trimmed = input.trim();
            if trimmed.chars().count() != 1 {
                println!("Please enter exactly one letter.");
            }else {
                ch = trimmed.chars().next().unwrap();
            }

            println!("Processing letter: {:?}", ch);
            if s.contains(ch) {
                println!("Letter {:?} is already guessed.", ch);
                char_array.iter_mut().enumerate().for_each(|(i, c)| {
                    if s.chars().nth(i).unwrap() == ch {
                        *c = ch;
                    }
                });
            } else {
                println!("Letter {:?} is not guessed yet.", ch);
                chance -= 1;
            }

            if !char_array.contains(&'_') {
                println!("You won the game!");
                println!("The word was: ",);
                char_array.iter().for_each(|c| print!(" {} ", c));
                println!("\n");
                std::process::exit(0);
            }
            hungman(chance, &s);
    }   
}

fn hungman(i : i8, s : &str) {
    match i 
    {
        6 => {
            println!(
                r#"
        ============================================



                ^
        ============================================
        "#
            );
        }
        5 => {
        println!(
                r#"
        ============================================


                |
                ^
        ============================================
        "#
            );
    }
    4 => {
        println!(
                r#"
        ============================================

                |
                |
                ^
        ============================================
        "#
            );
    }
    3 => {
        println!(
            r#"
        ============================================
                ____
                |
                |
                ^
        ============================================
        "#
            );
    }
    2 => {
        println!(
            r#"
        ============================================
                ____
                |   O
                |
                ^
        ============================================
        "#
            );
    }
    1 => {
        println!(
            r#"
        ============================================
                ____
                |   O
                |  /|\
                ^   
        ============================================
        "#
            );
    }
    0 => {
        println!(
            r#"
        ============================================
                ____
                |   O
                |  /|\
                ^  / \
        ============================================
        "#
            );
        println!("You lost the game!");
        println!("The word was: {:?}", s);
        println!("\n");
        std::process::exit(1);
        }
    _ => {
        println!( "Something went wrong, please try again!"  );
        }
    }
}

#[derive(Deserialize)]
struct ApiResponse {
    data: WordsPage,
}

#[derive(Deserialize)]
#[serde(rename_all = "camelCase")]
struct WordsPage {
    words: Vec<String>,
    total_pages: u32,
}

fn fetch_words_page(word_length: u32, page: u32) -> Result<WordsPage, reqwest::Error> {
    let url = format!("https://api.poocoo.pl/api/v1/words?length={word_length}&page={page}");
    let response: ApiResponse = reqwest::blocking::get(&url)?.json()?;
    Ok(response.data)
}

fn get_random_word_from_rest_api(word_length: u32) -> Result<String, reqwest::Error> {
    let total_pages = fetch_words_page(word_length, 1)?.total_pages;
    println!("totalPages = {total_pages}");

    let page = fetch_words_page(word_length, rand::random_range(1..=total_pages))?;
    let index = rand::random_range(0..page.words.len());
    Ok(page.words[index].clone())
}

fn main() {
    let word_length = rand::random_range(3..=10);
    println!("Random search for a word in a dictionary");
    //let word = random_word::get_len(word_length, Lang::En);
    let word = get_random_word_from_rest_api(word_length).expect("failed to fetch word");
    //println!("Found word: {:?}", word);
    guess_word(&word);
}

This is a publicly available REST API you can use for your projects and tests. Be careful about the number of calls you send, as sometimes it can return an HTTP 429 Error, this means you exceeded the rate limit. Don't overdo it; they accept 120 requests per minute per IP address.

ModSecurity is a WAF module which integrates with Apache HTTP Server and analyses incoming traffic using predefined security rules. It is commonly deployed with the OWASP Core Rule Set (CRS), which provides protection against common web application attacks, this is how I installed it on Fedora Linux Server for my Nextcloud

Instalation and basic config

 dnf install httpd mod_security mod_security_crs

Restart Apache to load the module :

systemctl restart httpd

Check if is loaded:

 httpd -M | grep security

Expected:

security2_module (shared)

The main ModSecurity configuration file is typically located at: /etc/httpd/conf.d/mod_security.conf Edit /etc/httpd/conf.d/mod_security.conf and set:

SecRuleEngine DetectionOnly

In this mode, ModSecurity evaluates incoming HTTP requests and logs potential security violations, but does not execute disruptive actions defined by WAF rules.

SecAuditEngine RelevantOnly
SecAuditLog /var/log/httpd/modsec_audit.log
SecAuditLogParts ABIJDEFHZ

And here is the important thing: DetectionOnly does not disable ModSecurity. Security rules are still evaluated, and suspicious requests are logged. This makes it possible to understand how the WAF behaves with real production traffic before enforcing blocking rules.

Monitoring:

Look at files like this:

• /var/log/httpd/modsec_audit.log (Detailed WAF security events)
• /var/log/httpd/error_log (ModSecurity warnings and Apache errors)
• /var/log/httpd/access_log (HTTP requests and response status codes)

or monitor all events i you have more files like me:

tail -f /var/log/httpd/*

This is really helpful grep which you can use to find the Rule Ids that were triggered:

grep -oE '\[id "[0-9]+"\]' /var/log/httpd/* | sort | uniq -c | sort -nr

For Fedora installations using OWASP CRS 4, exclusions can typically be placed in:

/etc/httpd/modsecurity.d/activated_rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

For example, suppose the /api/editor/save endpoint accepts HTML content and triggers false positives for rule 941100. Instead of disabling the rule globally, exclude a specific parameter for that endpoint:

SecRule REQUEST_URI "@streq /api/editor/save" "id:10001,phase:1,pass,nolog,t:none,ctl:ruleRemoveTargetById=941100;ARGS:content"

It is also possible to disable an entire rule for a particular endpoint:

SecRule REQUEST_URI "@streq /api/legacy"  "id:10002,phase:1,pass,nolog,t:none,ctl:ruleRemoveById=942100"

Validate and reload Apache:

apachectl configtest
systemctl reload httpd

Best practices for exclusions:

• Prefer parameter-level exclusions over disabling entire rules.
• Restrict exclusions to specific endpoints whenever possible.
• Assign unique IDs to custom rules.
• Document the reason for each exclusion.

Change the mode

Finally, you can switch to active blocking mode; it is simply as simple as changing:

SecRuleEngine DetectionOnly

to

SecRuleEngine On

modsecurity can work on a side server in proxy mode with modproxy on Apache.

A long time ago, I implemented this for the website szkla.com. The architecture diagram:

+—————+ +——————————+ +———————+ | | | Apache WAF Server | | | | Client | —> | ModSecurity | —> | Backend Server | | | | mod_proxy | | | +—————+ +—————————+ +———————–+ | | Blocked v HTTP 403