Habr•October 8, 2026•🇷🇺Translated from Russian

Tools Alone Won't Suffice: Building Systemic Kubernetes Security Across Hundreds of Clusters at Alfa-Bank

Alfa-Bank has operated Kubernetes clusters for more than ten years and reports that over 53 percent of Russian companies now use vanilla Kubernetes, yet security outcomes remain poor. According to the Red Hat “State of Kubernetes Security 2024” report, 46 percent of organizations suffered financial losses due to insufficient Kubernetes security, and nine out of ten experienced at least one container or Kubernetes-related incident.

Alexander, lead of the K8S and cloud security department, argues that the root cause is not a lack of tools—more than 100 security products exist—but the absence of a systemic process framework. Before the bank adopted such a framework, requirements, incidents, and audits existed in isolation, and teams had no accurate inventory of clusters or their configurations.

Process Map Built Around the Threat Lifecycle

The bank groups its processes into a pipeline that follows the threat lifecycle: detect, prevent, verify, control, and respond. Every process begins with threat modeling that feeds into security requirements, which are then communicated to delivery teams, validated through reviews and audits, and supported by runtime monitoring and incident response. The resulting map closely resembles classic security operations workflows rather than Kubernetes-specific tooling checklists.

Responsibility for each step is defined using a RACI matrix that distinguishes Responsible, Accountable, Consulted, and Informed parties. This matrix is applied across domains because cluster security depends on node security, business workload security depends on the cluster, and vice versa.

Key Process Areas

  • Threat modeling draws on commercial feeds, public research, and internal intelligence; the security team owns the model and maps scenarios to requirements.
  • Requirements are translated into architecture patterns for single-tenant and multi-tenant clusters, plus scripts, playbooks, and audit policies developed jointly with DevOps teams.
  • Project expertise is coordinated by AppSec Business Partners who route relevant projects to the Kubernetes security team for validation against patterns and specifications.
  • Audits combine automated and manual detection of misconfigurations, contextual validation with delivery teams, remediation tracking against SLAs, and two-stage inventory covering both clusters and their internal objects.
  • Risk assessment serves as the final control when technical mitigation is impossible; the Kubernetes team contributes mitigation descriptions and risk scenarios.
  • Platform operations run on four dedicated clusters managed entirely by the security team.
  • SOC integration supplies log-collection policies, detection signatures, and playbooks while the SOC team leads primary incident response.

Competency Model and Staffing

Four roles cover the required breadth of skills: Architect (sets foundational decisions), Analyst/Engineer (implements and operates processes), Auditor (drives the full audit lifecycle and tooling), and Platform DevOps Engineer (maintains observability and platform stability). With more than 500 clusters ranging from six to over 300 nodes, the bank determined that these four specialized positions are the minimum needed to sustain the system.

Related articles

Habr•Other

Detecting Suspicious Processes in Linux: How to Investigate Unknown Services, Network Connections and Startup Tasks

This practical guide helps Blue Team beginners investigate unexpected resource usage, unknown network connections, and processes that restart after reboot on Linux systems. It explains how to examine running processes with ps and top, identify executable paths via /proc, and review network sockets using ss and lsof without installing additional tools. The article covers checking systemd services with systemctl, reviewing cron jobs and timers, auditing SSH keys, and correlating events from journalctl logs. Emphasis is placed on gathering multiple indicators rather than jumping to conclusions about compromise, as high CPU usage or unfamiliar services can stem from legitimate misconfigurations or maintenance tasks. Readers learn safe evidence preservation steps if suspicious activity is confirmed, including logging observations and avoiding immediate reboots that could destroy forensic data.

Habr•Other

TLS Fingerprinting Explained: From Handshakes in TLS 1.2/1.3 to JA3, JA4, HTTP/2 Analysis and uTLS Evasion

The article provides an in-depth examination of how TLS handshakes reveal client identity even before any HTTP data is sent. It traces the evolution from early SSL versions developed by Netscape to modern TLS 1.3, highlighting how elliptic curve cryptography and AEAD ciphers reduced latency while increasing observability challenges for defenders. Detailed breakdowns show why JA3 hashes became unreliable due to GREASE randomization and extension ordering changes, prompting the shift to the more robust JA4+ family that uses sorted, GREASE-resistant blocks for stable fingerprints. The piece also covers HTTP/2 fingerprinting signals and practical tools such as uTLS in Go for mimicking browser TLS stacks and Finch for traffic analysis. Real Wireshark captures of Client Hello packets to GitHub illustrate how Cloudflare and WAF systems detect scripted clients despite matching User-Agent headers. Overall, the content serves as both a historical overview and a hands-on guide for security engineers working on bot mitigation and traffic obfuscation.

Habr•Other

Centralized Secret Management: Comparing Eight Tools for DevOps and Spring Boot Applications

The article examines the challenges of managing secrets such as passwords, API tokens, and SSH keys across development, CI/CD pipelines, and production environments. It explains how centralized secret registries solve issues like scattered .env files, outdated credentials, and lack of audit trails while emphasizing that delivery mechanisms to applications must be chosen separately. Key concepts including static versus dynamic credentials, leases, rotation, and machine identities are defined to help teams implement least-privilege access. The review compares Infisical, HashiCorp Vault, OpenBao, Doppler, 1Password CLI, Bitwarden Secrets Manager, Passbolt, and Yandex Lockbox across deployment models, offline support, and integration options. Special attention is given to CLI run commands that avoid plaintext files, Spring Cloud Vault integration, and the trade-offs between SaaS convenience and self-hosted control. Practical recommendations focus on separating developer and machine access as well as development and production environments.

AntiMalware•Other

Opera Rolls Out Local AI Processing via WebAI Standard in Opera One Browser

Opera has introduced an early implementation of WebAI, a proposed web standard that enables websites and extensions to run AI models directly on the user's device instead of relying on remote servers. The feature debuts in Opera One and will later expand to Opera GX and Neon. Supported models include Google's Gemma as well as Apple's local foundational model on compatible Mac hardware, with no vendor lock-in. Key capabilities cover text generation, content classification, and analysis of relationships between information fragments. Developers gain the ability to add AI features without building server infrastructure or incurring per-query cloud costs, while users avoid subscriptions to external AI services. All processing occurs locally on an opt-in basis, keeping data off cloud providers, although performance depends on the device's hardware capabilities.