Implementing 2FA Kubernetes Access via Gateway API, Dex and MULTIDIRECTORY
A Russian cybersecurity firm has published a detailed account of replacing static, long-lived kubeconfig certificates with corporate accounts and mandatory two-factor authentication across its Talos Linux Kubernetes clusters.
The previous approach relied on exchanging root kubeconfig files through a password vault. Each certificate was valid for a year, worked from any location, and could not be revoked without rotating the cluster CA. When an employee left or a laptop was lost, the credentials remained active.
Target requirements
The team defined four goals: login with corporate credentials, enforced second factor, cluster rights derived from directory groups, and a kubeconfig file containing no secrets.
Architecture components
- Talos Linux 1.13 as the immutable operating system
- Kubernetes v1.33
- ArgoCD for GitOps management
- NGINX Gateway Fabric 2.6 implementing Gateway API
- Dex 0.24 as the OIDC provider
- kube-oidc-proxy performing token validation and impersonation
- MULTIDIRECTORY as the LDAP source of truth for users, groups and 2FA policies
MULTIDIRECTORY supplies both LDAP attributes and 2FA enforcement. Dex connects to it with a standard LDAP connector; the second factor itself is configured only inside the directory, so neither Dex nor Kubernetes is aware of its existence.
Groups returned by Dex are placed in the OIDC token claim and forwarded by kube-oidc-proxy. Standard ClusterRoleBinding objects then grant permissions to those groups, allowing access changes to be performed solely by editing directory membership.
Single-host routing with Gateway API
All traffic arrives at one FQDN. An HTTPRoute splits requests among three backends: Dex OIDC endpoints, a Python kubeconfig generator, and kube-oidc-proxy. The catch-all rule for “/” does not override more specific prefixes, a behavior that differs from classic NGINX location ordering.
The generated kubeconfig uses the kubelogin exec plugin. It contains only the public cluster address, CA data and client ID; no certificates or tokens are embedded.
Gateway API migration issues
The team encountered several non-obvious problems. Routes placed in a different namespace from the Gateway were silently rejected because the listener defaulted to “Same” namespace. Explicitly setting allowedRoutes.namespaces.from: All resolved the issue. BackendTLSPolicy required the exact hostname present in the backend certificate rather than the internal service name, otherwise 502 errors occurred. Finally, the OIDC issuer URL had to remain identical inside and outside the cluster, solved with hostAliases on the proxy deployment.
All cluster-specific values were externalized into Kustomize patches and ArgoCD Application values, making the configuration reusable across additional clusters without code changes.
Related articles
Passkeys in Production: How One Developer Replaced Passwords with Face ID in Three Days Using FastAPI and Next.js
Yaroslav Morozov details a complete production implementation of Passkeys based on the WebAuthn standard and FIDO2 protocols. The article explains why Passkeys eliminate phishing and database breach risks compared to traditional passwords while providing biometric login via Face ID or Touch ID. It covers database schema design with PostgreSQL tables for credentials and challenges, SQLAlchemy models, and minimal dependencies including py-webauthn on the backend and SimpleWebAuthn on the frontend. Full working code for registration and authentication flows is provided, showing how Passkeys integrate with existing JWT token systems without major refactoring. The guide includes environment configuration, error handling, challenge management with five-minute TTL, and security considerations such as sign count verification to detect cloned keys.
Yandex Disk Files Become Partially Inaccessible After Sasovo Data Center Incident
A detailed user report reveals that approximately one percent of files stored on Yandex Disk are currently unavailable for download following reported incidents at the Sasovo data center. The problems manifest in three distinct states: missing thumbnails with downloadable originals, visible thumbnails with inaccessible originals returning 504 Gateway Time-out errors, and cases where both thumbnails and originals fail to load. Technical analysis using curl requests traced the failures to specific storage nodes such as s418klg.storage.yandex.net, indicating that some data shards may reside in affected infrastructure while others remain operational. Yandex support requested original files for diagnosis but closed the ticket without providing an official explanation or confirming data integrity. The author emphasizes that the issue affects files across both the Photos and Files sections and recommends maintaining offline backups due to the lack of guaranteed availability during data center failures.
Keurig K-Supreme Smart Coffee Maker Generates Nearly 1 TB of Outbound Traffic in Ten Days
A Keurig K-Supreme Smart coffee maker unexpectedly produced around 1008 GB of outgoing traffic over ten days, overwhelming a home UniFi access point while generating only 9.94 GB of inbound data. The device had been placed on a separate network segment, yet the traffic remained largely internal to the home LAN rather than traversing the internet connection. The anomaly was discovered by user Nomad while assisting family members with network maintenance through the UniFi dashboard. After the coffee maker was powered off, the issue could not be reproduced in subsequent testing, and no packet captures were available to determine the content or root cause of the traffic. The model requires internet connectivity for remote control, scheduling, capsule recognition, and automatic reordering of coffee supplies. No similar incidents have been reported by other users, and the manufacturer has not issued any statement regarding the event.
Hash Functions Part 1: Core Properties, Security Requirements and Practical Applications
The article provides a detailed introduction to hash functions, explaining how they map arbitrary-length input to fixed-length output while satisfying three fundamental security properties. It covers preimage resistance, second preimage resistance, and collision resistance, along with the avalanche effect that makes even minor input changes produce unrecognizable output. The text explains why a 256-bit digest is required to achieve 128-bit collision resistance, referencing the birthday paradox and its implications for MD5 and SHA-1. Practical guidance includes using OpenSSL for hashing, applying hashes in commitment schemes, enforcing subresource integrity on web pages, and securely storing passwords with Argon2 and bcrypt. The post emphasizes that hash functions alone do not guarantee integrity without proper transmission of the digest and announces a follow-up on SHA-2 and SHA-3 internals.