As a result, we jointly drew up a program and agreed on the date of the two-day course.
What did you focus on
We were practice-oriented, so it was required that all students have at least a basic understanding of containerization. Some were fine with this, but some did not fully understand the difference between containerization and traditional virtualization. For surface diving, we prepared a self-study program, which included:
Familiarization with video materialslectures 1–7;
Familiarization with materials and completing a practical task on deploying the simplest container application (required for beginners and optional for those who need to remember);
Performing a lab that consists of deploying and performing basic operations with containerized applications (mandatory for some students).
And here’s what it looked like the program of the course itself:
1st day. Security of Cloud-Native-applications
Dive into Cloud-Native specifics
Thinking Transformation to Cloud-Native-Security
Introduction to Kubernetes
On the first day, we looked at what Cloud-Native approach and security are. In the process, we learned what security classes and approaches exist today for Cloud Native applications based on the Cloud Native Computing Foundation (CNCF) classification. All this was divided into phases of the application life cycle: Develop, Distribute, Deploy, Runtime. And the last stage was also divided into parts: Compute, Storage and Access. We also ran through the topics of Threat Modeling, Threat Intelligence, Incident Response, Least Privilege, etc. We ended the first day with a little introduction to Kubernetes with an eye on security and sources of information useful for working with it.
2nd day. Container security, Kubernetes and their mechanisms
On the second day, we looked at what it consists of and what underlies the security of containers and Kubernetes. We discussed defense issues, possible actions of attackers and examples of real incidents. Among the topics covered were: Image security, Container runtime security (escapes from containers), Host security, Network security, Kubernetes security (control plane), Application security. Each topic was covered with live examples using open source tools, which was especially helpful. We considered the security mechanisms that Kubernetes provides: RBAC, Network Policy, PodSecurityPolicy, Admission controllers, Service Accounts, Secrets, Audit Policy. We ended with an overview of freely available sites, projects for honing skills in protecting and attacking Kubernetes, talking about the risk analysis approach in Kubernetes, and possible ways to implement self-protecting and ZeroTrust.
During the intensive, we considered many practical cases, actual problems of organizing complex protection of microservice architectures and ways to solve them.
It is important to note that both days were present 100% listeners. This at least indicates not only the relevance of the topic itself, but also the interest in it on the part of our employees (thanks to the popularity of various combinations of words: sec, dev, ops). And now, when the word “containerization” is heard, a group of specialists immediately gathers to jointly look for options for solving the problem.
It turned out lively, as useful as possible … But, to be honest, it’s hard because of the high concentration of useful material on the topic. Although we encounter it much more often than a year ago, but still not every day. More than half of the students revisited the material over the weekend and took notes to use the knowledge gained in upcoming projects.
Our future plans
This case influenced the approach to organizing training in the future – we will continue to try to find practitioners who have been dealing with a topic of interest to us every day for several years.
As for securing containerization environments, for now we decided to focus on the following:
building the correct architecture of the containerization environment;
maximum use of the built-in protection mechanisms of Kubernetes and operating systems (this will eliminate unnecessary points of failure and maintain manageability);
the use of external solutions for monitoring the current state and ongoing processes (it’s hard to call the regular functionality convenient);
use of specialized security analysis tools and well-known classical protection tools.
IN focus we will keep:
FSTEC requirements regarding the use of certified host operating systems;
Russian external monitoring and management tools (we are very much looking forward to when Luntry completes the process of certifying its solution);
Russian protective equipment adapted for containerization;
Russian containerization/orchestration systems.
In general, we do not sit still, we love to study, if you too – join to our team. Always happy to drive colleagues!