Security on Backend Engineering Strategy Tools

IaC Scanning

Mon, 08 Jun 2026 00:00:00 +0000

Static analysis for infrastructure code. Scan Terraform, Helm, Kubernetes manifests, Dockerfiles, and CloudFormation before they are applied. The goal is catching misconfigurations — open security groups, missing encryption, public S3 buckets — in the same pipeline that runs your application tests.

These tools do not require running infrastructure. They read the source and flag violations against a built-in rule library, with optional custom rule support.

Checkov

Checkov is a static analysis tool from Bridgecrew (now Prisma Cloud). Large built-in rule library for Terraform, Helm, Kubernetes, Dockerfiles, GitHub Actions, and more. Custom rules in Python or YAML.

pip install checkov
# or
brew install checkov

# Scan a Terraform directory
checkov -d ./infra/

# Scan a specific file
checkov -f main.tf

# Scan Kubernetes manifests
checkov -d ./k8s/ --framework kubernetes

# Scan a Helm chart
checkov -d ./charts/myapp/ --framework helm

# Output as JSON
checkov -d ./infra/ -o json

# Skip specific checks
checkov -d ./infra/ --skip-check CKV_AWS_20,CKV_AWS_57

Output shows passed/failed checks per resource with the check ID, description, and file:line reference.

Custom policies (YAML)

metadata:
 name: "Ensure S3 bucket has MFA delete enabled"
 id: "CKV2_AWS_CUSTOM_1"
 category: "ENCRYPTION"
scope:
 provider: terraform
definition:
 cond_type: attribute
 resource_types: ["aws_s3_bucket"]
 attribute: mfa_delete
 operator: equals
 value: "Enabled"

Trivy (IaC mode)

Trivy is primarily a container image vulnerability scanner, but its --scanners misconfig mode covers IaC. One tool, multiple surfaces — useful when you are already using Trivy for image scanning and want consistent output.

brew install trivy

# Scan Terraform
trivy config ./infra/

# Scan Kubernetes manifests
trivy config ./k8s/

# Scan a Helm chart
trivy config ./charts/myapp/

# Include severity filter
trivy config --severity HIGH,CRITICAL ./infra/

# JSON output
trivy config -f json ./infra/

Trivy’s IaC rules are sourced from Trivy’s built-in checks — the same checks engine used by tfsec (Trivy absorbed tfsec in 2023).

tfsec

tfsec was a standalone Terraform-focused scanner, now maintained as part of Trivy. The standalone CLI still works and is simpler if you only scan Terraform.

brew install tfsec

tfsec ./infra/
tfsec ./infra/ --severity HIGH
tfsec ./infra/ --format json

Most teams migrating from tfsec to Trivy get equivalent coverage with trivy config.

Comparison

	Checkov	Trivy config
Terraform	Yes	Yes
Kubernetes	Yes	Yes
Helm	Yes	Yes
Dockerfile	Yes	Yes
GitHub Actions	Yes	No
Custom rules	Python / YAML	Rego
Also scans	—	Container images, Git secrets, SBOMs
Maintained by	Prisma Cloud	Aqua Security

For a team already using Trivy for image scanning, extending to IaC with trivy config keeps the toolchain simple. Checkov’s advantage is the broader coverage (GitHub Actions, Bitbucket Pipelines) and more mature custom rule support.

In CI

# GitHub Actions — Trivy IaC scan
- name: Trivy IaC scan
 uses: aquasecurity/trivy-action@master
 with:
 scan-type: config
 scan-ref: ./infra/
 severity: HIGH,CRITICAL
 exit-code: 1

# GitHub Actions — Checkov
- name: Checkov scan
 uses: bridgecrewio/checkov-action@master
 with:
 directory: infra/
 framework: terraform

Resources

SLSA — Supply-chain Levels for Software Artifacts

Wed, 03 Jun 2026 00:00:00 +0000

SLSA (pronounced “salsa”) is a framework for securing the software supply chain. Developed by Google, now under the OpenSSF. The core question it answers: how do you know the artifact you are deploying is actually what was built from the source you think it was?

The answer is provenance: cryptographically signed metadata that records what built an artifact, from what source, when, and under what conditions. SLSA defines levels of increasing rigour around how that provenance is generated and verified.

Why it matters

The software supply chain is an attack surface. SolarWinds, XZ Utils, Log4Shell — different attack vectors but the same underlying problem: something got into the build or the dependency that should not have been there, and nobody noticed until it was too late.

SLSA does not prevent all supply chain attacks. It makes certain classes of attack verifiably harder and gives consumers of an artifact a way to check that it was built the way it claims to have been.

The levels

SLSA defines three build levels (reorganised from the original four in SLSA v1.0):

L1 — Provenance exists The build produces signed provenance documenting what produced the artifact. Any build system, any format. Protects against accidental tampering and gives a starting point for verification.

L2 — Hosted build, signed provenance Build runs on a hosted CI platform (GitHub Actions, Cloud Build, etc.). Provenance is generated and signed by the build platform, not the developer’s machine. Harder to falsify — an attacker needs to compromise the build platform, not just a developer laptop.

L3 — Hardened build Ephemeral, isolated build environment. Non-falsifiable provenance — the build platform itself signs the provenance in a way that even a compromised build script cannot forge. Parameterless builds where the inputs are fully declared.

Provenance in practice

Provenance is a JSON document (SLSA uses the in-toto Attestation Framework) that records:

The source repository and commit
The build platform and workflow
The artifact digest(s)
The builder identity

It is signed using Sigstore / cosign, which provides keyless signing backed by OIDC identity. No key management required for the common case.

Tooling

SLSA GitHub Generator: reusable GitHub Actions workflows that generate SLSA L3 provenance for common artifact types (Go binaries, container images, Maven/Gradle packages). The easiest path to L3 on GitHub Actions.

cosign: signs and verifies container images and provenance attestations. Part of the Sigstore project.

slsa-verifier: CLI tool to verify SLSA provenance against an artifact. Used by consumers to check that an artifact meets a required SLSA level.

Dependency Track / Grype / Trivy: SBOM and vulnerability scanning tools that complement SLSA (SLSA is about build integrity, SBOM is about knowing what is in the artifact — related but distinct).

SLSA and container images

Container images are a natural fit. The image digest is the artifact, provenance attests to the build that produced it, cosign attaches the attestation to the registry.

# verify an image has SLSA provenance
slsa-verifier verify-image \
 ghcr.io/myorg/myimage@sha256:abc123 \
 --source-uri github.com/myorg/myrepo \
 --source-tag v1.0.0

For the tooling images pattern — images published to a registry that teams depend on — SLSA provenance is worth adding. It gives consumers a verifiable chain from source to image.

Practical adoption

L1 is low friction. Generate provenance as part of the build, attach it to the release. Most CI platforms make this straightforward.

L2 requires a hosted build platform (most teams already use one) and using the platform’s signing rather than rolling your own.

L3 requires workflow changes — ephemeral environments, parameterless builds, using the SLSA GitHub Generator or equivalent. More investment but achievable for a standard GitHub Actions project.

Start at L1. Provenance exists, the chain is documented, the habit is established. L2 and L3 follow naturally as the pipeline matures — you are not making a big architectural decision, you are incrementally tightening what you already have.

In practice: never seen L1, L2, or L3 required explicitly by a client or platform. It is still “good idea in theory” territory for most teams. That said, the underlying practices — signed builds, traceable artifacts, reproducible pipelines — show up as requirements all the time, just not always under the SLSA name.

Which points to what SLSA actually is: a name and a framework for practices that are already good ideas. Automate the build, sign the output, record the provenance. Quality follows from automation — it frees up time to iterate, makes review easier, and ensures consistency without manual discipline. SLSA formalises that and gives you a vocabulary to talk about it with others. The levels are a ladder, not a checklist to complete before you can ship.

Shared Tooling Images: SLSA provenance applies directly to published tooling images
GitHub Actions: where SLSA GitHub Generator workflows run

Bastion / jump server

Fri, 22 May 2026 00:00:00 +0000

A bastion host (jump server) is a single, hardened machine exposed to the outside that acts as the entry point into a private network. You SSH into the bastion, then hop from there to internal hosts — or configure your SSH client to do it transparently in one step.

The pattern is simple: minimise the network attack surface to one well-monitored machine, harden that machine specifically, and keep everything else off the public internet.

Basic jump: manual two-hop

# Step 1: SSH into the bastion
ssh user@bastion.example.com

# Step 2: from bastion, SSH into internal host
ssh user@192.168.1.100

Works, but requires your private key to be on the bastion — which you want to avoid.

ProxyJump (recommended)

ProxyJump tells SSH to tunnel through the bastion transparently. Your key never leaves your local machine.

# One-liner
ssh -J user@bastion.example.com user@192.168.1.100

# Or in ~/.ssh/config
Host internal
 HostName 192.168.1.100
 User user
 ProxyJump bastion

Host bastion
 HostName bastion.example.com
 User user
 IdentityFile ~/.ssh/id_ed25519

After this, ssh internal works as a single command with no key on the bastion.

Agent forwarding vs ProxyJump

Agent forwarding (-A, ForwardAgent yes) forwards your SSH agent socket through the bastion so you can authenticate onward with your local key. Older approach — it works but the agent socket is briefly accessible on the bastion host, which is a lateral movement risk if the bastion is compromised.

ProxyJump is strictly better for the common case: the connection to the internal host is established from your machine through an SSH tunnel, not from the bastion itself. No agent socket on the bastion.

Use ProxyJump unless you specifically need agent forwarding for something else.

Hardening basics

A bastion is only useful if it’s actually hardened. Minimum:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers jumpuser

Key-only authentication — no passwords
Dedicated user with no shell access to the bastion itself (optional: ForceCommand to restrict what they can do)
Non-standard port reduces log noise, not actual security
fail2ban or equivalent for rate-limiting auth attempts
Minimal installed software — the bastion should do one thing
Regular log review (/var/log/auth.log)

Restricting to jump-only

If you want users to be able to jump through the bastion but not get a shell on it:

# In authorized_keys, prefix the key with:
restrict,port-forwarding ssh-ed25519 AAAA...

Or use AllowTcpForwarding yes with ForceCommand /usr/sbin/nologin — though the interaction between these options is subtle; test carefully.

For making the bastion reachable from outside without a public IP → Tunnels
For exposing internal web services via public URLs → Tunneled reverse proxy platforms

Kyverno

Mon, 01 Jan 2024 00:00:00 +0000

Kyverno is a policy engine for Kubernetes. It runs as an admission controller and intercepts every resource creation or update, applying rules that validate, mutate, or generate resources. Policies are written as Kubernetes CRDs in YAML — no Rego, no separate language to learn. If you can write a Kubernetes manifest, you can write a Kyverno policy.

Three rule types

Validate — reject resources that don’t meet requirements:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: require-labels
spec:
 rules:
 - name: check-team-label
 match:
 any:
 - resources:
 kinds: [Deployment]
 validate:
 message: "Deployments must have a 'team' label."
 pattern:
 metadata:
 labels:
 team: "?*"

Mutate — automatically add or modify fields on admission:

- name: add-default-resources
 match:
 any:
 - resources:
 kinds: [Pod]
 mutate:
 patchStrategicMerge:
 spec:
 containers:
 - (name): "*"
 resources:
 requests:
 +(memory): "64Mi"
 +(cpu): "250m"

Generate — create related resources automatically. A common use: generate a NetworkPolicy every time a new namespace is created.

Enforcement vs audit

Policies run in enforce mode (block non-compliant resources) or audit mode (allow but report violations). Audit mode is the right starting point — understand your existing state before enforcing.

Common policies

The Kyverno policy library has ready-made policies for common requirements: disallow privileged containers, require image tags to not be latest, enforce resource limits, restrict hostPath mounts. Most teams start from the library and customise.

Resources

Linux Identity Management — FreeIPA and SSSD

Mon, 01 Jan 2024 00:00:00 +0000

Managing user accounts across many Linux machines by hand — creating the same user on every host, syncing passwords, maintaining sudo rules — breaks down fast. FreeIPA provides centralised identity management: one place to define users, groups, sudo rules, host policies, and SSH keys. SSSD is the daemon that runs on each Linux machine and connects it to FreeIPA (or any LDAP/Kerberos provider), making those central definitions available locally.

FreeIPA

An integrated identity management solution from Red Hat, combining LDAP (389 Directory Server), Kerberos, DNS, a certificate authority, and a web UI into a single deployable stack. Users, groups, sudo rules, HBAC (host-based access control) rules, and SSH public keys are all managed centrally and enforced on enrolled hosts. FreeIPA is the open source upstream of Red Hat Identity Management (IdM).

Install on RHEL/Rocky/AlmaLinux:

dnf install freeipa-server
ipa-server-install --domain=example.com --realm=EXAMPLE.COM

Once the server is running, enroll a client host:

dnf install freeipa-client
ipa-client-install --server=ipa.example.com --domain=example.com

After enrollment, users defined in FreeIPA can log into the host with Kerberos SSO — no separate account needed on the machine.

SSSD

The System Security Services Daemon. SSSD runs on each Linux host and mediates all identity lookups — NSS (name service switch) queries for users and groups, PAM authentication, sudo rule lookups. It caches responses locally so logins still work when the identity server is temporarily unreachable, and it handles the Kerberos ticket lifecycle transparently.

SSSD is not FreeIPA-specific. It supports:

FreeIPA (the natural pairing)
Active Directory (via the ad provider — direct AD integration without Samba)
Generic LDAP and Kerberos

The ipa-client-install command configures SSSD automatically when enrolling a FreeIPA client. For AD integration, the configuration is similar but uses the ad provider:

[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_domain = example.com
krb5_realm = EXAMPLE.COM

The pairing

FreeIPA and SSSD are complementary halves of the same solution. FreeIPA is the authoritative store — where you create and manage identities. SSSD is the enforcer on each host — it translates FreeIPA’s policies into local authentication decisions, caches them for resilience, and keeps Kerberos tickets current. Neither replaces the other; together they give you centralised identity management with no single point of failure for login availability.

Resources

LUKS — Linux Disk Encryption

Mon, 01 Jan 2024 00:00:00 +0000

LUKS (Linux Unified Key Setup) is the standard for full-disk encryption on Linux. It uses dm-crypt in the kernel to encrypt block devices transparently — the filesystem sits on top of an encrypted layer, and the encryption happens below it. The LUKS header stores the encrypted key material and metadata, supporting up to eight independent key slots (passphrases or keyfiles) that all unlock the same volume.

Setup

# Encrypt a device (destroys existing data)
cryptsetup luksFormat /dev/sdb

# Open the encrypted device, exposing it as a plaintext mapper device
cryptsetup luksOpen /dev/sdb data-encrypted

# Format and use the plaintext device normally
mkfs.ext4 /dev/mapper/data-encrypted
mount /dev/mapper/data-encrypted /mnt/data

# Close when done
umount /mnt/data
cryptsetup luksClose data-encrypted

Key slots

LUKS supports multiple passphrases or keyfiles — useful for adding a recovery key alongside an operational passphrase:

# Add a second key slot (e.g. a recovery keyfile)
cryptsetup luksAddKey /dev/sdb /path/to/recovery.key

# Remove a key slot
cryptsetup luksRemoveKey /dev/sdb

# List key slot usage
cryptsetup luksDump /dev/sdb

Auto-unlock at boot

For encrypted root or data partitions that should unlock automatically on boot, add the device to /etc/crypttab with a keyfile path:

data-encrypted /dev/sdb /etc/keys/data.key luks

Then add the plaintext device to /etc/fstab as normal. On servers, the keyfile is stored on a separate volume or fetched from a secrets manager (Vault, Tang/Clevis for network-bound disk encryption).

Use in Kubernetes

Node-level disk encryption with LUKS protects data at rest on Kubernetes worker nodes — persistent volume data stored on the node’s disks is encrypted before it leaves the kernel. Talos Linux enables LUKS encryption for its state and ephemeral partitions by default.

Resources

Managing Secrets in Kubernetes

Mon, 01 Jan 2024 00:00:00 +0000

Kubernetes has a built-in Secret resource, but it is not a secrets management solution — it is base64-encoded storage with no encryption at rest by default and no access audit trail. How you actually manage secrets in a Kubernetes cluster depends on how far you need to go beyond the default.

Native Kubernetes Secrets

The baseline. A Secret is a key-value store mounted into pods as environment variables or files:

apiVersion: v1
kind: Secret
metadata:
 name: db-credentials
type: Opaque
data:
 username: YWRtaW4=  # base64("admin")
 password: cGFzc3dvcmQ=

The problems: base64 is encoding, not encryption. Secrets are stored in etcd — enabling etcd encryption at rest is a cluster configuration step that is easy to skip. Secrets are visible to anyone with kubectl get secret in that namespace. For anything beyond a local dev cluster or a low-sensitivity workload, you need something more.

Sealed Secrets

A Kubernetes controller from Bitnami. SealedSecret resources contain secrets encrypted with the cluster’s public key — only the controller running in that cluster can decrypt them. The encrypted form is safe to commit to Git, which makes GitOps workflows possible without a separate secrets store. Simple to operate, no external dependency. The tradeoff: secrets are tied to a specific cluster’s key, cross-cluster sharing requires re-encryption, and there is no centralised audit trail.

External Secrets Operator

ESO reads secrets from an external store (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault, 1Password) and syncs them into native Kubernetes Secrets. Your source of truth stays in the external system; the K8s Secret is a read-only projection of it, refreshed on a configurable interval:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
 name: db-credentials
spec:
 refreshInterval: 1h
 secretStoreRef:
 name: aws-secrets-manager
 kind: ClusterSecretStore
 target:
 name: db-credentials
 data:
 - secretKey: password
 remoteRef:
 key: prod/db/password

ESO is the right choice when you already have a secrets store and want Kubernetes workloads to consume from it without changing how secrets are managed elsewhere.

Secrets Store CSI Driver

An alternative to ESO for the same problem: mount secrets from an external store directly as files in a pod, without creating a Kubernetes Secret at all. The secret materialises only in the pod’s filesystem, is not stored in etcd, and disappears when the pod terminates. Supported by AWS, Azure, GCP, and Vault providers. Used in combination with a SecretProviderClass to define what to fetch and where to mount it.

HashiCorp Vault

A dedicated secrets management platform. Vault stores arbitrary secrets, issues dynamic credentials (database passwords that expire, AWS IAM credentials valid for an hour), manages PKI, and provides a full audit log of every read and write. Kubernetes workloads authenticate to Vault via the Kubernetes auth method (using the pod’s service account token) and receive a Vault token scoped to the secrets their service account is allowed to read. More to operate than the other options, but the right answer for organisations that need dynamic credentials, fine-grained access control, and audit logs.

Summary

Approach	Good for
Native Secrets	Local dev, low-sensitivity workloads
Sealed Secrets	GitOps, single-cluster, no external dependency
External Secrets Operator	Syncing from existing external stores
Secrets Store CSI	Avoiding etcd entirely, file-based secret injection
HashiCorp Vault	Dynamic credentials, audit logs, enterprise requirements

Resources

Security Scanning & Monitoring

Mon, 01 Jan 2024 00:00:00 +0000

Security tooling broadly splits into three concerns: what vulnerabilities exist in your software before it runs (image scanning), what is actually happening on your systems while they run (endpoint monitoring), and what is moving across your network (intrusion detection). Clair, osquery, and SNORT each cover one of these.

Clair

A static analysis tool for container image vulnerability scanning, from the Quay project (Red Hat). Clair maintains a database of CVEs from multiple sources (NVD, Red Hat, Debian, Alpine, Ubuntu) and matches them against the packages installed in a container image layer by layer. Integrated into a container registry, it scans every image on push and blocks or flags images with known vulnerabilities above a configurable severity threshold. The result is a vulnerability report tied to the image digest — not the running container, but the image itself before it’s ever deployed.

osquery

Facebook’s open source endpoint monitoring tool. osquery exposes the operating system as a relational database — processes, users, network connections, installed packages, kernel modules, scheduled tasks, browser extensions — all queryable with SQL. This makes ad-hoc security investigation fast (a single query answers “which processes are listening on unexpected ports?”) and continuous monitoring straightforward (schedule queries, collect results centrally, alert on anomalies). osquery runs on Linux, macOS, and Windows. Used standalone it is a powerful investigation tool; integrated with a SIEM or fleet management layer (Fleet, Kolide) it becomes a continuous compliance and detection platform.

-- Processes with open network connections
SELECT p.name, p.pid, l.address, l.port
FROM processes p
JOIN listening_ports l ON p.pid = l.pid
WHERE l.port NOT IN (22, 80, 443);

SNORT

A network intrusion detection and prevention system (IDS/IPS). SNORT inspects network traffic in real time against a ruleset — signatures for known attack patterns, protocol anomalies, port scans, exploit attempts. In IDS mode it logs and alerts; in IPS mode it can drop matching packets inline. SNORT rules are expressive and the community ruleset (Snort Community Rules, Emerging Threats) covers a wide range of threats. Placed at a network chokepoint — in front of a server, at the edge of a network segment — it gives visibility into what traffic is actually reaching your systems and can detect lateral movement, exfiltration attempts, and known exploits in transit.

Resources

SSH

Mon, 01 Jan 2024 00:00:00 +0000

SSH (Secure Shell) is the standard protocol for encrypted remote access to Linux and Unix systems. It replaced telnet and rsh by wrapping the session in a cryptographic tunnel — authentication, commands, and data transfer all protected against interception and tampering.

Public key authentication

The default auth mechanism for any serious setup. You generate a key pair: a private key that never leaves your machine, and a public key that goes on the remote host.

ssh-keygen -t ed25519 -C "your@email.com"
ssh-copy-id user@host # appends public key to ~/.ssh/authorized_keys on remote

Prefer ed25519 over the older rsa — smaller keys, faster, stronger. Keep your private key protected with a passphrase; use ssh-agent to avoid typing it repeatedly.

Key deployment at scale

When you have many hosts, distributing public keys manually doesn’t scale. A typical pattern: submit your public key to a central approval system, which then deploys it to the relevant hosts via automation (Ansible, Puppet, etc.).

This keeps a clear audit trail — keys are approved, recorded, and can be revoked centrally without touching individual authorized_keys files.

Certificate authentication

At larger scale, even centralised key distribution gets unwieldy. SSH certificates solve this properly: instead of deploying individual public keys, you run an SSH Certificate Authority (CA). Hosts and users trust the CA, not each other’s individual keys.

Generate a key pair locally
Submit the public key to the SSH CA (backed by your identity provider — FreeIPA, Vault, etc.)
The CA issues a signed certificate with a short TTL
SSH to any host — the host trusts the CA, so the certificate is accepted without any pre-deployed keys

Short-lived certificates (hours, not days) dramatically reduce the blast radius of a compromised credential. No revocation lists to maintain.

SSH config

~/.ssh/config avoids repetitive flags on every connection:

Host bastion
 HostName bastion.example.com
 User deploy
 IdentityFile ~/.ssh/id_ed25519
 ForwardAgent yes

Host internal-*
 ProxyJump bastion
 User deploy

ProxyJump (formerly -J) lets you reach hosts that aren’t directly accessible — you SSH through the bastion transparently.

Port forwarding

SSH can tunnel TCP traffic, useful for reaching services on private networks:

# Local forward: reach remote Postgres via localhost:5432
ssh -L 5432:db.internal:5432 bastion

# Dynamic forward: SOCKS proxy through the bastion
ssh -D 1080 bastion

Hardening basics

Key settings in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy ansible

Disable password auth entirely once keys are in place. Restrict which users can log in. Run sshd -t to validate config before reloading.

Resources

TLS Certificates — Let's Encrypt, Certbot, cert-manager

Mon, 01 Jan 2024 00:00:00 +0000

TLS certificates prove that a server is who it claims to be and encrypt traffic in transit. Getting and renewing them used to mean manual requests to a CA, waiting days, and calendar reminders to renew before expiry. Let’s Encrypt automated the entire process in 2015 and made it free. Today there is no reason to run a public service without TLS.

Let’s Encrypt

A free, automated, open certificate authority run by the Internet Security Research Group. Let’s Encrypt issues Domain Validation (DV) certificates valid for 90 days, automatically, via the ACME protocol. The short lifetime is intentional — it forces automation and limits the window if a certificate is compromised. Let’s Encrypt is now the largest CA in the world by certificates issued. You never interact with Let’s Encrypt directly; you use an ACME client that speaks the protocol on your behalf.

Certbot

The EFF’s ACME client — the most widely used way to obtain and renew Let’s Encrypt certificates on a Linux server. Certbot handles the ACME challenge (proving you control the domain), fetches the certificate, installs it into your web server config (nginx, Apache), and sets up a cron job or systemd timer for automatic renewal. For a straightforward public-facing server, Certbot is the default choice:

certbot --nginx -d example.com -d www.example.com

Certbot supports HTTP-01 challenges (serve a file over port 80) and DNS-01 challenges (add a TXT record — required for wildcard certificates and useful when port 80 isn’t accessible).

# Wildcard cert via DNS challenge
certbot certonly --manual --preferred-challenges dns -d "*.example.com"

Renewals run automatically. Check the timer is active:

systemctl status certbot.timer

cert-manager

The Kubernetes-native way to manage certificates. cert-manager runs as a controller in the cluster and automates the full certificate lifecycle — requesting, renewing, and storing certificates as Kubernetes Secret resources. It supports Let’s Encrypt via ACME (HTTP-01 and DNS-01 challenges) as well as other issuers (Vault, Venafi, self-signed).

A ClusterIssuer configures the CA once for the whole cluster:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-prod
spec:
 acme:
 server: https://acme-v02.api.letsencrypt.org/directory
 email: admin@example.com
 privateKeySecretRef:
 name: letsencrypt-prod
 solvers:
 - http01:
 ingress:
 class: alb

A Certificate resource then requests a cert for a specific domain — or an Ingress annotation triggers cert-manager automatically. The certificate is stored as a Secret and mounted into pods or referenced by the Ingress. Renewal happens automatically before expiry.

Security on Backend Engineering Strategy Tools

IaC Scanning

Checkov

Custom policies (YAML)

Trivy (IaC mode)

tfsec

Comparison

In CI

Resources

SLSA — Supply-chain Levels for Software Artifacts

Why it matters

The levels

Provenance in practice

Tooling

SLSA and container images

Practical adoption

Related

Bastion / jump server

Basic jump: manual two-hop

ProxyJump (recommended)

Agent forwarding vs ProxyJump

Hardening basics

Restricting to jump-only

Related

Kyverno

Three rule types

Enforcement vs audit

Common policies

Resources

Linux Identity Management — FreeIPA and SSSD

FreeIPA

SSSD

The pairing

Resources

LUKS — Linux Disk Encryption

Setup

Key slots

Auto-unlock at boot

Use in Kubernetes

Resources

Managing Secrets in Kubernetes

Native Kubernetes Secrets

Sealed Secrets

External Secrets Operator

Secrets Store CSI Driver

HashiCorp Vault

Summary

Resources

Security Scanning & Monitoring

Clair

osquery

SNORT

Resources

SSH

Public key authentication

Key deployment at scale

Certificate authentication

SSH config

Port forwarding

Hardening basics

Resources

TLS Certificates — Let's Encrypt, Certbot, cert-manager

Let’s Encrypt

Certbot

cert-manager

Resources