In the previous blogs, we learned about stages and common patterns of deployment and microservices deployment strategies. This article will introduce how to deploy applications securely.
While security is a critical part of the Software Development Life Cycle (SDLC), it also needs to be part of every aspect of the SDLC, especially deployment. Therefore, securing application deployment doesn't start at the deployment stage, but rather, security needs to be factored in from the first line of code written, i.e., the security left shift.
This article will cover 6 best practices for securing application deployment to help you avoid security issues. These best practices will also ensure that the speed of the deployment process is not compromised.
1. Control the trigger method of deployment
Development teams should carefully manage code that triggers automated deployment to production environments, and production deployments should not be made from untrusted codebases, forks, or branches.
2. Understand the security of the development environment
Before spinning up a new project, it is critical to familiarize the development team with security best practices for the relevant system environment. For example, the Kubernetes security context setting can help the development team understand the basics of Kubernetes security. Once the development team understands these basics, human error can be greatly reduced.
This is important because Kubernetes is one of the fastest-growing open source projects in history and is widely used for cloud-native development and deployment, and a deep understanding of Kubernetes security best practices can help teams avoid security mistakes, as can other container orchestration systems.
3. Implement a secret policy
When dynamic services are used to handle configuration changes, they (or similar services) should also handle the associated secrets. They pass the secrets to the container at runtime while using a consistent policy for handling secrets to ensure that different types of secrets (i.e., runtime vs. build secrets) are not confused and that testing and development are smooth.
Applications only need to build secrets at packaging time (e.g., project repo or file storage credentials). Runtime secrets are only needed after deployment (e.g., private keys, database passwords, and SSL certificates), so developers only need to pass the necessary secrets to the application.
It is important to maintain a consistent key handling policy across all environments to facilitate secret tracking. The policy should be flexible enough to allow for testing and deployment, with the focus being on the secrets' use rather than its origin.
4. Adopt GitOps practices
GitOps is becoming the preferred approach for secure cloud-native and Kubernetes-centric CI/CD. It offers both security and rapid deployment, two crucial aspects of any software development project today.
GitOps is a set of practices for Kubernetes environments, particularly when a single cluster resource is shared by multiple users or teams.
GitOps can be used in collaboration with Kubernetes features, such as namespaces, to ensure secure resource usage among multiple tenants. This is achieved by maintaining isolation between tenants and reducing security and readability risks. GitOps is particularly useful when multiple users are making changes, as it ensures that any changes made are tracked and approved before being incorporated into the final build. This feature enables you to manage updates to your application and easily revert to a previous version if an update fails to meet expectations.
5. Never use the default configuration
When using open-source projects, it is important to avoid using their default configuration. The default configuration may not align with your security policy as it prioritizes business success, operations, and features over security. Additionally, default configurations are often common knowledge and can be exploited by attackers. It is recommended to seek support from vendors to ensure a secure configuration.
When using Kubernetes, deployments and their pods do not have a network segmentation policy, which allows all assets to communicate with each other. While this default setting is convenient for quick application development, it also means that if a container is attacked, the threat can spread quickly.
6. Running automated tests as part of a deployment
Well-designed tests can increase confidence in the security of your code. Conversely, poorly designed tests can hinder progress. Whenever possible, automate tests to support the deployment pipeline. Simple tests can be run every time you make a change to your code, while resource-intensive tests can be saved for major releases. Failed tests should not be ignored; instead, re-evaluate and refactor tests that do not work.
Conclusion
Securing software deployments requires collaboration between development and security teams to ensure security is considered throughout the software development lifecycle. This article outlines 6 best practices for securing software deployments to help safeguard your software processes. For further information on application deployment, please refer to our previous articles:
Basics of App Deployment 01: 3 Main Stages, 4 Common Patterns
Basics of App Deployment 02: Top 3 Deployment Strategies for Microservices
Welcome to the community!
Discord: https://discord.gg/fXZUKK2baF
Twitter: https://twitter.com/Seal_io
LinkedIn: https://www.linkedin.com/company/seal-io