Alek's Blog - security

ingress-nginx Retirement: Four Ways Forward

aleks — Sat, 18 Jul 2026 00:00:00 +0000
The ingress-nginx</code> Kubernetes controller is not “retiring soon.” It already has. The GitHub repository was archived and made read-only on 2026-03-24, and its own description now reads in the past tense: it was</em> an Ingress controller. For a piece of software that reportedly still runs in front of roughly half of all cloud-native workloads, that is a completed fact, not a countdown.</p>
This is Part 1 of a field guide to migrating away from it. This part is deliberately non-technical — it is for whoever has to decide what to do</em>, not yet for whoever will do the migration work. Parts 2 onward get concrete: inventorying what you actually depend on, an annotation compatibility matrix, migration mechanics, and a reproducible lab.</p>


Istio AuthorizationPolicy & HTTP/2 Coalescing
aleks — Mon, 13 Jul 2026 00:00:00 +0000
Isolating an admin surface behind its own hostname and an IP-restricted
Istio</a> AuthorizationPolicy</code> sounds like a Tuesday-afternoon change: add a
second HTTPRoute</code>, add a DENY</code> policy with an allowlist, done. Two non-obvious Envoy behaviors
turned it into a two-day debugging exercise instead — one in how AuthorizationPolicy</code> resolves
“the client’s IP,” and one in how browsers reuse HTTP/2 connections across hostnames that share a
certificate. Neither is specific to Keycloak or to this particular setup; both apply to any Istio
or Envoy Gateway API ingress sitting behind a cloud load balancer with a shared wildcard
certificate.</p>
This post walks through both bugs, how they were root-caused, and the fix for each — so the next
person hitting either symptom can skip straight to the cause.</p>


K8s & OpenShift: Compliance
aleks — Wed, 01 Jul 2026 00:00:00 +0000
Part 6</a> covered the operational loop:
GitOps, observability, cost control, and upgrades. This final part maps the cluster configuration
covered throughout this series to the regulatory frameworks that require it — NIS2, DORA,
PCI-DSS, HIPAA, and the Cyber Resilience Act (CRA) — and covers the two topics that compliance
work adds on top of security: audit logging as evidence and log retention as a contractual
obligation.</p>


K8s & OpenShift: Security
aleks — Wed, 01 Jul 2026 00:00:00 +0000
Part 4</a> covered scaling and resilience.
This part covers security — not as a checklist to complete before an audit, but as a set of
controls that reduce real attack surface and limit the blast radius when something goes wrong.</p>


K8s & OpenShift: Building Workloads Right
aleks — Wed, 01 Jul 2026 00:00:00 +0000
Part 1</a> covered the business case and
organisational framing. This part goes inside the pod: image hygiene, security context, health
probes, graceful shutdown, and the application design choices that determine whether a workload
actually fits the platform.</p>


What is Application Security
aleks — Sat, 20 Jun 2026 00:00:00 +0000
The third part of the (D)DoS series — but a step sideways: this post covers attacks at the Application layer that affect confidentiality and integrity</strong> rather than availability. SQL Injection, Log4Shell, and similar vulnerabilities have a different threat model than the DDoS attacks covered in the technical part</a>.</p>


What is a (D)DoS - technical
aleks — Sat, 20 Jun 2026 00:00:00 +0000
The technical follow-up to the non-technical (D)DoS overview</a>. Covers Layer 3/4 network floods (SYN, UDP, amplification), BGP hijacking, Layer 7 application DDoS, and operational resilience — all focused on availability.</p>
Originally published at opensourcerers.org</a>; updated with current attack vectors and technologies.</p>


What is a (D)DoS
aleks — Sat, 20 Jun 2026 00:00:00 +0000
(D)DoS attacks are not just a technical problem — they operate at the Business, Social, and Informational level as well. This post covers the non-technical dimensions; the technical follow-up</a> covers Layer 3/4 network floods, BGP hijacking, TLS handshake attacks, Layer 7 application DDoS, and operational resilience.</p>
Originally published at opensourcerers.org</a>; updated with current examples and expanded framing.</p>


(D)DoS and Application Security: The Complete Guide
aleks — Fri, 19 Jun 2026 00:00:00 +0000
This is the index and reading guide for a three-part series on denial-of-service and application
security. The first two parts cover availability</strong> attacks — a service being made unreachable or
unusable — at levels most people don’t associate with the term “DDoS”: the business level (losing
the people who run the service), the social level (manipulating the humans behind it), the
informational level (reputational disruption), and finally the technical level most readers expect
(network floods, BGP hijacking, Layer 7 exhaustion). The third part is a deliberate step sideways,
into application-layer attacks — SQL Injection, Log4Shell, the OWASP Top 10 — that threaten
confidentiality and integrity</strong> instead of availability.</p>


Log Archiving Security & Compliance: AWS / GCP / Azure / OVHcloud
aleks — Thu, 14 May 2026 00:00:00 +0000
This post covers the security and compliance dimension of the
managed log archiving comparison</a>:
encryption, access control, immutability for regulatory retention, GDPR, and compliance
certifications relevant for EU/DACH environments.</p>

Full guide:</strong> AWS vs. GCP vs. Azure vs. OVHcloud: The Complete Guide to Managed Log Archiving</a></li>
Part 1 — Overview & Cost:</a> Services, storage model, 7-year cost comparison</li>
Part 2 — Pre-Flight, Flexibility & Auditor Export:</a> Pre-flight checklist, retroactive flexibility, auditor export</li>
Part 3 — Operations:</a> Kubernetes integration, ingest pipeline, backup & DR</li>
Part 4 — Security & Compliance — this post:</strong> IAM/RBAC, encryption, WORM, GDPR, compliance certificates</li>
Part 5 — Query, Dashboards & Recommendations:</a> Query interfaces, dashboards, alerting, cold-tier behaviour, when to use which</li>
Part 6 — Production Checklist, Guardrails & Runbooks:</a> Loss detection, privacy, schema, cost guardrails, runbooks, fire drills</li>
</ul>
Self-hosted alternative: Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse — Part 3 (Security)</a></em></p>


Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: Security & Compliance
aleks — Thu, 14 May 2026 00:00:00 +0000
Access control, encryption, and immutability requirements often determine whether a log
archive can be used for compliance purposes — and the five systems differ substantially in
what they enforce natively versus what must be delegated to infrastructure.</p>
This is Part 3 of a five-part series.</p>

Full guide:</strong> Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: The Complete Guide</a></li>
Part 1 — Comparison:</a> Storage tiering, compression, resource consumption, query languages, SaaS options</li>
Part 2 — Operations:</a> Setup, ingest pipeline, ECS vs. OTel, backup & DR, observability, alerting</li>
Part 3 — Security & Compliance — this post:</strong> Encryption, RBAC, WORM / S3 Object Lock</li>
Part 4 — UX, Dashboards & Alerts:</a> UI layers, log search UX, cold-tier query behaviour, dashboard building, sharing, alerting</li>
Part 5 — Use Case:</a> Vector, Istio/Envoy, nginx, Java on OVH MKS — complete ClickHouse ingestion setup and monthly awffull report</li>
</ul>


Istio vs. Linkerd: Service Mesh on Kubernetes
aleks — Tue, 12 May 2026 00:00:00 +0000
Both Istio</a> and Linkerd</a> are CNCF Graduated service
meshes that provide automatic mTLS, traffic policy, and observability for Kubernetes
workloads. Both run in sidecar mode for this comparison — a proxy container injected into
every pod. The fundamental difference is the data plane: Istio uses
Envoy</a>, Linkerd uses its own Rust-based proxy
(linkerd2-proxy</code></a>). That choice drives the differences in overhead, extensibility, and egress
control.</p>
This post compares them on the dimensions that matter for a production deployment. For the
broader question of Istio vs. Envoy Gateway (ingress-only), ambient mode, and managed cloud
specifics (AKS, GKE, OVH MKS), see the companion post
Istio vs. Envoy Gateway: Gateway API on Kubernetes</a>.</p>


Istio vs. Envoy Gateway: Gateway API on Kubernetes
aleks — Thu, 30 Apr 2026 00:00:00 +0000
Both Istio</a> and Envoy Gateway</a> implement the
Kubernetes Gateway API</a> and use Envoy as their data plane.
That is roughly where the similarity ends. Istio is a full service mesh that happens to
implement Gateway API; Envoy Gateway is a dedicated Gateway API controller with no mesh
ambitions. Choosing between them is mostly a question of scope.</p>
This post starts with that comparison — architecture, mTLS, egress control, and resource
overhead — then broadens to cover Cilium</a> as a lighter alternative for
East-West security, how the choice plays out on managed Kubernetes offerings (AKS, GKE, and
OVH MKS including their cloud-native ingress and egress options), and finally how to get
the real client IP through a cloud load balancer to your application.</p>