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
PT AF Cloud Uses Machine Learning to Detect Shifts in Web Attack Patterns from Millions of WAF Events
Positive Technologies has detailed how its PT AF Cloud service applies anomaly detection to WAF events, turning tens of millions of daily security events into actionable weekly alerts for SOC teams. The system builds traffic profiles based on the distribution of triggered protection rules for each tenant and compares current hourly or daily profiles against a weighted historical baseline using Jensen-Shannon distance. This approach identifies meaningful changes in attack composition even when overall event volume remains stable, catching the start of scans, exploitation of newly published vulnerabilities, or post-release application changes that trigger new rules. Two detection modes operate in parallel: an hourly mode for rapid spikes and a daily mode for gradual shifts distributed across multiple hours. Alerts include comparative tables of top rules, unique attack vectors, and direct links to the relevant events in the PT AF interface. Over four weeks the detector surfaced roughly 1,100 anomalies across the cloud, with expert review confirming that 69 percent indicated either an attack or a protection misconfiguration.
How to Prepare Your Website for Data Center Outages: Business Resilience Checklist
Following strikes on Yandex data centers, many businesses discovered that their sites and all backups were stored in a single location, leading to complete outages. The article provides a detailed checklist to mitigate such risks by separating critical components across different providers. Key recommendations include moving DNS to an independent provider, lowering TTL values, maintaining a live mirror site on separate hosting, and isolating corporate email. Additional steps cover local backups, monitoring, access management, and CDN usage. The guidance differentiates between virtual hosting, VPS or dedicated servers, and website builders like Tilda, while emphasizing compliance with Russian data localization laws such as 152-FZ.
How to Properly Compare CDNs: TTFB, p95 Latency, Caching, DDoS Protection and True Pricing
Selecting a CDN based solely on the number of points of presence is as unreliable as choosing a car by dashboard buttons. Networks with dozens of global PoPs may underperform for audiences concentrated in Novosibirsk or Yekaterinburg, while smaller regional providers often deliver superior peering with Russian operators. The article evaluates CDNVideo, EdgeCenter, Curator, NGENIX and Yandex Cloud CDN across verifiable features, network design, caching behavior, security controls, operations and commercial models. Performance data is separated because marketing claims cannot substitute for independent measurements from services such as CDNMON. Emphasis is placed on p95 metrics, cache hit ratios, origin shielding, raw logs and API limits rather than marketing scores. The analysis shows that no single universal ranking exists; optimal choice depends on traffic profile, audience geography, security requirements and operational workflows.
Innostage Lab Benchmarks PT NGFW 1.10.3 Performance in Eight Load Scenarios
Innostage researchers conducted extensive performance testing of PT NGFW version 1.10.3, the certified release at the time of trials. The evaluation covered TCP connection setup rates, concurrent session capacity, and throughput on a custom EMIX traffic profile with varying security modules enabled. Tests used Cisco TRex generators and a high-rule-count policy of 100,000 entries to simulate realistic enterprise conditions. Results showed the device sustaining 700,000 CPS and 6.4 million concurrent connections, matching or approaching vendor claims under HA-cluster configuration. Throughput remained above 27 Gbps even with IPS, application control, antivirus, NAT, URL filtering, and logging active. The report highlights differences in test methodology compared with vendor figures, including packet sizes and clustering setup.