MeridianMeridian

Implementing 2FA Kubernetes Access via Gateway API, Dex and MULTIDIRECTORY

A Russian cybersecurity company replaced static kubeconfig files with corporate accounts and mandatory 2FA for its Talos Linux Kubernetes clusters. The solution routes all authentication through a single FQDN using NGINX Gateway Fabric, Dex as an OIDC provider connected to MULTIDIRECTORY via LDAP, and kube-oidc-proxy for token validation and impersonation. Groups stored in the directory are passed directly into RBAC bindings, eliminating manual certificate management. A lightweight Python service dynamically generates kubeconfig files that contain no secrets. The team documented several Gateway API migration pitfalls including namespace route restrictions and BackendTLSPolicy hostname validation. The approach keeps the entire configuration in Git and avoids modifying kube-apiserver flags.

HabrTranslated from Russian

Read at source

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.

ArgoCDTalos LinuxDexMULTIDIRECTORYGateway APIkube-oidc-proxy
ShareXFacebookLinkedInReddit
Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Other

Mail.ru Reduces Lifetime 1TB Cloud Storage Promo to Standard 8GB Quota for Select Users
Other

Mail.ru Reduces Lifetime 1TB Cloud Storage Promo to Standard 8GB Quota for Select Users

Mail.ru has begun notifying a small group of long-term Cloud Mail users that their complimentary 1TB storage, originally granted through a 2013-2014 app installation promotion, will be reduced to the standard 8GB free tier. Affected users receive personalized deadlines, with some facing storage limits starting 30 October and final deletion of excess files scheduled for 30 January 2027. The company confirmed the change impacts fewer than 0.5 percent of Cloud Mail users and stated that core free features remain available. Once the 8GB limit is exceeded, uploads, edits, and sharing are blocked while users have three months to download data or purchase additional space before files move to the trash for 14 days prior to permanent removal. This follows a similar reduction of lifetime 100GB storage performed by the service in 2024.

AntiMalwareOct 29, 2026Translated from Russian

Kimi K3 Open Model Surpasses Closed AI Leaders with Million-Token Context and 896 Experts
Other

Kimi K3 Open Model Surpasses Closed AI Leaders with Million-Token Context and 896 Experts

Kimi K3 is an open-weights model that outperforms closed systems from GPT and Anthropic on several independent benchmarks. Developers achieved this by scaling three dimensions simultaneously: one million tokens of context, deeper layers, and 896 Mixture-of-Experts specialists. The team replaced the standard KV-cache with a fixed-size state matrix updated via the delta-rule, solving numerical instability by clamping the forgetting coefficient alpha between e^-5 and 1. Sequential state updates were parallelized across chips, GPUs, and multi-GPU nodes using the open-source FlashKDA kernel built on CUTLASS. Inter-layer information flow was preserved through learned pseudo-queries that selectively retrieve relevant outputs from prior blocks rather than passing full activations. Load balancing across 896 routed experts uses per-expert quantile thresholds and a distributed histogram method to guarantee fair token allocation without full sorting.

HabrOct 29, 2026Translated from Russian

Innostage Completes Functional Testing of PT NGFW 1.10.3 Across 156 Criteria
Other

Innostage Completes Functional Testing of PT NGFW 1.10.3 Across 156 Criteria

Innostage has published the second part of its evaluation of PT NGFW version 1.10.3, focusing on functional capabilities rather than raw performance. The testing covered 156 individual checks grouped into categories such as basic technical features, firewalling, IDS/IPS, web filtering, malware protection, logging, routing, deployment, cryptographic controls and access management. Out of the total, 136 checks passed fully, seven passed with remarks, and 13 did not meet the predefined criteria. Key confirmed functions include high-availability clustering, centralized management via PT-MNGT, AD-based rule application, Site-to-Site VPN, TLS inspection, and Syslog integration with external security systems. Several advanced scenarios, including custom block pages, application risk classification, and centralized software distribution, were not confirmed under the test conditions. The report provides detailed protocol notes that help organizations map product capabilities against their specific infrastructure and regulatory requirements.

HabrOct 29, 2026Translated from Russian