Kubernetes has taken a central place in how containerized applications are managed. Therefore, there are many agreed file formats that define Kubernetes applications, including YAML, JSON, INI, etc.
This leads us to consider what the best strategy for our application is. Also, we have to consider how the application configuration will be validated against the chosen file structure (especially security) paths.
In this article, we'll explore the use of YAML files to define Kubernetes applications, and the various steps that can be taken to effectively validate these configuration definitions.
Yaml defines K8s configuration
Compared to JSON and INI, YAML is more compact and readable. For example, if we were to define a pod that is reachable on port 80, the configuration in YAML, JSON, and INI would look like the table below.
It's clear that YAML simplifies the way we define Kubernetes applications, especially considering that a common application may involve dozens of configuration files. Additionally, the compact nature of YAML allows you to group objects together, reducing the number of files required.
However, there are significant challenges when defining Kubernetes configuration files, especially when embedding constraints and relationships between manifest files. For example, how do we ensure memory limits are configured according to best practices?
Lack of validation not only leads to unexpected behavior of the application when corner cases are met, but also exposes major security holes. Therefore, it is necessary for us to consider the validation strategy based on the yaml configuration file, which is what we will delve into in the following sections.
verify content
Three levels of validation should be performed on YAML files. These levels ensure that validation is performed against the actual validity of the YAML file until security practices are met.
The first level is fabric validation, which is a base level validation performed on Kubernetes configuration files. It just needs to validate the YAML file to make sure there are no syntax errors. This can be verified by the IDE when writing the configuration file.
The second layer is semantic verification. This ensures that the contents of the YAML file are translated into the required Kubernetes resources, thereby authenticating the Kubernetes application itself.
Finally, the third and deepest layer of validation is security validation to ensure that there are no vulnerabilities in the defined Kubernetes application. We may have successfully written the YAML configuration and also successfully implemented the required Kubernetes resources and connections, but this does not ensure that our Kubernetes application is secure and follows best practices. The last two validations are both Kubernetes configuration validations, and not just in terms of YAML format validation. Because it is application-dependent, special authentication is required. Performing such validations requires in-depth and specialized knowledge in the Kubernetes domain, and we will briefly describe how they can be easily handled using tools developed by Kubernetes domain experts.
For example, locking down hostPath mount permissions ensures that containers in a cluster with writable hostPath volumes cannot be accessed by attackers who could gain persistence on the underlying host. This is not in line with security best practices, to avoid this issue we should always ensure that the readOnly section under the hostPath property is set to true.
Another example is granting pods host network access only when necessary. All pods with permissions should be whitelisted. Unnecessary access to the host network increases the potential attack surface.
So, as you can see from the two examples above, even if our configuration files pass structural and semantic validation, resulting in our Kubernetes resources being successfully orchestrated, security and functional vulnerabilities may still exist. Therefore, we must consider how best to catch these vulnerabilities and then alert them to the consequences in a production environment. Security verification is the way to do this.
Best Practices for Validating Yaml
Considering that structure verification is quite simple, the IDE usually used for programming integrates this function. Kubernetes semantics and security validation require special treatment, especially in terms of policies and tooling.
We consider some best practices and strategies to achieve comprehensive validation of YAML files.
You can do a dry run ( kubectl apply -f - -dry-run='server " ) to verify the semantic structure, but this is still an extra step and may slow down the overall speed. However, the dry run requires you to have access to Kubernetes cluster.
Another option for this approach is Kubeval, a utility that can be used to validate configuration file semantics to ensure they meet Kubernetes' object definition requirements. It can be part of the CI process and perform the scan locally, ensuring configuration files are semantically validated before going into production.
Security verification can also be implemented in CI using kuscape. This is an open source tool that ensures your Kubernetes application definitions adhere to multiple security frameworks such as NSA-CISA or MITER ATT&CK®. By using the kuscape CLI, you can scan all YAML files for security vulnerabilities and even get risk scores and risk trends. It acts as a YAML validator whose main value is security validation.
From DevOps to DevSecOps
You can run a combination of the tools already discussed in the CI pipeline for structural, semantic, and security validation. However, leveraging these tools and their predefined checks is not enough.
One of the things we learn from DevOps is that there is always a cycle of improvement that can be adopted. That's why you should continually review your security controls as your application evolves and your security requirements change.
New security controls should be incorporated into the security verification step. kuscape is an open source platform developed by AMRO, which allows you to define your own control framework. Although the out-of-the-box framework is robust, policy controls need to be formed according to the specific needs of the business and Kubernetes resources.
This best practice can only be achieved by embedding security checks into building applications. Thanks to open source tools like Kubeval and kuscape, the hurdles for development teams to keep thinking about verification, especially security verification, have been lowered.
Summarize
YAML configuration files make building Kubernetes applications very simple. However, YAML does have its limitations when it comes to validation. Therefore, it is necessary for us to understand all validation strategies to ensure that the built Kubernetes applications are healthy and safe.
Verifying the structure of a YAML file is fairly straightforward using YAML testing in any IDE, but verifying the correctness of Kubernetes resource object definitions and the security measures surrounding them is difficult. Luckily, tools like kuscape bridge this gap, continuously considering security throughout the application lifecycle.
Since security is one of the main concerns in building container applications, the authentication strategies discussed here are a step in the right direction.
Link: https://blog.csdn.net/weixin_44592002/article/details/127884503