There is an exhaustive list of security measures that a security administrator needs to take before and after a release is performed. This number expands when it comes to a large organization that has multiple applications and a higher tendency to get attacked. Now, consider the fact that all these considerations need to be accounted for before each release. How much time and effort would have to go into ensuring the security of a system? This is a major problem when considering that a lengthy security audit process will make a well-defined and automated DevOps process useless. The aim of automated test and release pipelines is to release fast and consistently. This means that the development team would have already released another version of the application by the time the lengthy security audit process is completed. Once this version is audited and readied for release, two more versions will be out. You can imagine the extent of the problem here.
In the monolithic world, it was perfectly fine to wait until the development team had finished the product so that security auditing could start. Since releases weren't so frequent, the security team had enough breathing room between releases to do their job. Additionally, a microservice architecture increases the number of ways an attacker could attack. The whole cluster communicated via API endpoint, and there is generally a load of Kubernetes resources in an average cluster, which can all be exploited. Additionally, developers tend to use resources (such as images) created by other people, whose security they have no control over. While a monolithic system would not have this many issues, a microservice architecture makes your system more susceptible to attack and thereby makes the security team's job that much harder.
The solution proposed by DevSecOps was to simply move the security auditing phase with the rest of the DevOps process by integrating it with the DevOps lifecycle. This means that the developers themselves need to ensure that what they develop is up to the correct security standard, as they develop it. While the security team will still exist to ensure that security policies are enforced, a major part of securing the application will be out of their hands.
Now, you might be thinking that this is an extra load of work for the developers, and you might be right in some sense. After all, it will be up to you to release the working code. However, the available automation tools will take care of a lot of things for you. There is some overhead required for setting up the DevOps workflow, but everything from that point should be automated. You would generally set up builds that run per pull request. These builds will consist of pipelines that take raw source code from your branch, build it, run automated tests on it, and finally have a full set of security scans performed to ensure that your branch complies with all the requirements of releasing stable code. For example, if your final product is an image that you release to a container repository, the pipeline will first scan your code using something like Sonarqube to verify that it complies with the necessary coding practices, after which the actual image will be built. Then the image will be scanned for dependencies and cross-checked with a database to see if your image has any known vulnerabilities. There may be additional checks that come into play afterward, but that depends on what type of image you are creating.
The testing process doesn't need to stop here. Once you merge your changes with master, integration tests need to run to ensure that your changes play well with other changes. Once your image reaches a container repository, the repository runs regular periodical tests to ensure there are no new exploits that may affect your image. So at the end of the day, you as a developer will only have to keep these concepts in mind, and not have to actively manage the security of your application.
In the end, you will have a security system that is integrated into the development cycle, which will make the code you write much more secure and bug-free while minimizing the workload on the security team will ensure a faster release cadence. The best advantage is that fact that you will get instantaneous feedback on the state of your code. So if your code has some flaw or issue, it will be caught right inside your own branch, meaning that there is no consequence of making that mistake.
So what do these security measures mean? What parts of the release cycle need to have security steps integrated into them? Let's take a deep dive into a few different ways that you can secure your Kubernetes cluster.