Kubernetes has grown immensely, and its use within organizations is maturing.
While Kubernetes’ growth is exciting, security concerns around applications deployed on Kubernetes are mounting. Red Hat performed a survey with hundreds of DevOps professionals, and it showed that:
- 55% delayed application releases due to security issues
- 94% experienced at least one Kubernetes security incident in the past year
- 59% said security is their biggest concern as they continue to use Kubernetes and containers
Application Security Risks
Securing applications deployed on Kubernetes can be complex, especially if your applications are deployed across multiple clusters.
Securing applications end-to-end will require you to cover a large surface area and address items such as:
- Image scanning
- Control which registries developers can pull images from when deploying apps
- Visibility over application changes and events
- Network policies to ensure applications can only send and receive data as required.
- Pod security policy
- RBAC
- Quality of service
Application Security Stages
Building a strong security posture requires you to secure the complete lifecycle of your applications and be able to report and track changes that happen across the different stages.
Implementing security and addressing compliance requirements across these different stages while addressing the security risks mentioned above is difficult.
Today, most tools require you to develop and maintain cluster-specific and complex security, which makes it:
- Difficult to scale, especially as you adopt new clusters or technologies as part of the underlying stack
- Complex for security teams to adjust policies as compliance requirements change
- Not dynamic, so seeing how applications comply or violate policy changes can be daunting and time-consuming
- Difficult to onboard new members and have them quickly understand how your applications are secured
- Difficult to track application changes over time and how this affects your security posture
Application Security for … Applications
Because of the complexities above, Shipa took an application-centric approach to help DevOps and Platform Engineering teams secure their applications across different aspects and stages of their application lifecycle.
How secure are my applications?
That sounds like a simple question, right? But try answering that question when you have different teams deploying several services across different clusters!
If you go down the path of creating endless complex rules to answer that, it will take you time and only add complexity to your deliverables. In the end, you will have to not only create those rules but also manage them.
To address that, we will use Shipa’s application discovery capabilities. To get started, you can create a free account here.
Once you log into your account, head over to Frameworks and click on Create:
Shipa uses Frameworks to:
- Connect to your clusters
- Discover applications deployed
- Report on security and application support
You can create multiple frameworks to address scenarios such as different clusters, environments, projects, and more.
Select the Discover existing applications options and click on Next
Here, enter the following:
- Name: The framework name
- Plan: You can select the pre-created shipa-plan. You can create more plans later and see how discovered applications comply with a plan’s resource limits.
- Kubernetes Namespace: The namespace name to which this framework will be connected to
- Teams: Select the pre-created shipa-team. You can later create more teams and add them to a framework. This will limit the applications they can support using Shipa.
Click on Next
This step will ask you to enter:
- Label: The label used by your deployment definitions. This will be used by Shipa to discover applications deployed in the namespace defined in the previous step.
- Naming suffix: Any suffix you want Shipa to add to applications discovered. This is particularly important when you are discovering applications with the same name deployed to different clusters or namespaces.
Click on Create
With your framework created, you can connect it to a cluster by going to the Clusters page and clicking on Add.
With your framework connected to your cluster, in a few minutes, you will start seeing the applications discovered and how they comply with your initial framework configuration:
If you head back to your framework configuration, edit it, and add additional security requirements, such as Container Registry, Shipa will show an updated security report once you save it, creating a dynamic security model.
Application Security In Your Pipeline
Runtime security is excellent for understanding how applications are running, but securing applications even before they are in your CD pipeline is a great way to provide security end-to-end.
Shipa is releasing a capability that enables you to match your Helm Charts against a framework definition. If the Helm Chart configuration is in line with the framework definition, your application is sent to your CD pipeline, and the deployment is done.
This is a great feature for teams adopting GitOps, regardless of their tool of choice (FluxCD or ArgoCD). Since your application deployment definitions will be stored in Git, validating any changes before your GitOps tool deploys the applications can bring a strong security posture.
Here is an example of how you can use GitHub Actions and Shipa to validate your Helm configuration: https://github.com/brunoa19/shipa-ci-validation/blob/main/.github/workflows/podinfo.yml
The configuration above connects to your Shipa account and scans your Helm Chart to compare it with your framework configuration.
Here is the result when this action runs:
The report above shows the Action was stopped because my Helm Chart configuration was not compliant with the framework configuration.
If the Action passes the framework verification, Shipa will show a pipeline security report accessible through Shipa’s Insight page.
Conclusion
Shipa is providing a structured end-to-end security model for microservices-based applications. One that enables you to quickly define compliance models and apply them to your applications without the need to develop and maintain complex cluster-level security definitions.
In the next post, we will cover the CI stage security in more detail and how you can leverage different providers to create and maintain your security definitions.
