Hello everybody and welcome to the Cognixia podcast. How are you doing today? We have a rainy evening out here and today we are here to talk about another interesting topic that we are hoping would help you all be a little better at what you do. So, thank you for tuning in, and without further ado, let us begin today’s episode, shall we?
It won’t be an understatement to say that the most dangerous security holes are often pretty basic. Simple mistakes and oversights can be quite expensive. In today’s episode, we will talk about common security mistakes one can make while using Kubernetes. Anybody who uses Kubernetes would have encountered or heard of these errors at some point, and even if they haven’t, it is important to know about them. Fix these simple errors and we assure you; it will make a significant difference in how secure your applications are.
A lot of organizations these days are moving to creating and working with cloud-native applications. If your organization is one of them, then you are most likely working with Kubernetes. Kubernetes, after all, is the de facto standard for building containerized applications around the world. In fact, according to a recent CNCF report, 96% of organizations are either already using Kubernetes or evaluating the prospect of using Kubernetes to build and manage their applications. Kubernetes has over 5.6 million users spread all over the globe, which when you look objectively, you realize represents 31% of back-end developers. 31% may not sound too huge, but remember it is 31% of developers using one single platform – that is huge. The remaining 69% is divided between so many different platforms. Now, that is a significant market share. Moreover, this figure grows year-over-year, pushing up the amount of data that Kubernetes generates as well, in turn helping improve the platform. On the downside, it also makes Kubernetes a golden target for cybercriminals and unscrupulous elements, opening up certain vulnerabilities in your applications. Take it from us, a lot of these security issues will boil down to these basic security mistakes, which when checked will make a difference to your final clusters.
Simple Kubernetes Security Mistakes
Default Configurations
If you assume that the default cluster configuration in Kubernetes is good enough for everything you do, then you might want to reconsider your assumption, especially from a security perspective. We hate to break it to you but Kubernetes’ default settings are not top-notch security-grade. The default configuration settings in Kubernetes are designed to enable maximum flexibility and agility for the developers. As a user, it is an absolute must for you to ensure that configure your cluster appropriately from a security perspective.
Multiple Admins
If you or your team allows multiple people to use highly privileged roles like the CLUSTER_ADMIN role even for conducting day-to-day operations on clusters, then again, we hate to break it to you, but that could be an expensive mistake. The role assigned CLUSTER_ADMIN is a very high-level role that should be used to manage other roles and users, not for performing everyday tasks. So, if you are not someone who is authorized to manage other roles and users, then better avoid the CLUSTER_ADMIN role. When you have too many admins with the CLUSTER_ADMIN access, it opens up your clusters to multiple vulnerabilities, allowing hackers to take advantage of it. So, avoid it may be, and keep tight control on how many people are assigned the admin roles.
Unrestricted Access
This is something that gets overlooked so often that we can’t even begin to tell you, but if you think about it carefully you will realize this should be security 101! So many times, administrators simply don’t set access restrictions defining the type of access that different team members have to the dev/stage/prod clusters. Now, let’s be realistic here – not every team member would need unrestricted full access to everything. Restricting access is not a reflection of say distrust of team members, it is a wise move from a security perspective, and all your team members as well as the organization as a whole need to understand that. Allowing unrestricted access to everybody is a bad security practice. The logic behind this remains the same as having multiple administrators for your clusters – it makes your system more vulnerable to attack. So, assign roles carefully and restrict access to whatever is needed. If one needs access to something they don’t otherwise have access to, it can always be requested and granted on a case-to-case basis.
Assuming Isolation
A cluster network is not isolated from the larger virtual private cloud. This is something everybody must remember at all times. So, if you are someone who assumes otherwise, now is the time to change that belief. You cannot afford to overlook securing your virtual private cloud or your cluster network. Both need to be safeguarded against attacks. When this is not done, it is a welcome invitation for cybercriminals, something you might not exactly be looking forward to.
Vulnerable Imported YAMLs
Let’s face it, importing YAMLs saves valuable time for everybody, they are such a blessing. Thanks to YAMLs, you no longer have to reinvent the wheel every single time, and you save yourself from repeating the same mistakes as well as facing the same bugs again. You can relate to this, can’t you? But one thing you must never overlook is securing the YAMLs you import. Every YAML that gets imported and introduced to the new system must be secured so that the new ecosystem does not become vulnerable and the imported configuration issues can be sorted out as soon as possible.
Keeping Sensitive Information in ConfigMaps
Sensitive information such as passwords, tokens, keys, etc. must never be stored in ConfigMaps. We so often find developers doing that and it can be such a risky affair! We understand storing secrets in ConfigMaps is convenient and it is easily accessible but that is also the problem – it is easily accessible. This data could so easily be exploited by hackers if they gained access to it, which to be honest, is not all that difficult.
Skipping Regular Scans
Sometime back one of our experts had been telling us that so many organizations do not have any tools or plans in place for detecting any issues that they might encounter or that might be lurking in their Kubernetes environment. We were honestly shocked, but well, it is the sad truth. One of the easiest ways to detect the issues is to perform regular scans for misconfigurations and vulnerabilities. It is such a simple thing and so often gets skipped. The entire SDLC as well as the CI/CD pipeline should be scanned regularly for issues. Doing this ensures any issues that get discovered would be checked there themselves and would not make their way into production.
All these things are such simple, easy things to do, which is also probably why it gets skipped maybe? But not everything should have complex solutions and elaborate mechanisms. Sometimes, simple does the trick just fine, isn’t it? So is Kubernetes security. Ensure you don’t make these mistakes and you are already on your way to enhancing the security of your clusters.
With that, we come to the end of this week’s episode of the Cognixia podcast. We hope you enjoyed listening to us today. Again, we thank you for taking the time to listen to us and we promise to come back again next week with another interesting episode of the Cognixia podcast. Meanwhile, if you would like to get started on the path to learning more about Kubernetes and containers, do check out our Docker and Kubernetes learning course. You can visit our website and drop us a line on any of our social media handles to connect with us.
Until next week then! Happy learning.
