As Kubernetes adoption continues to grow and enterprises increasingly deploy production workloads, we’ve seen a lot of questions. Our recent Cloud Native Now webinar with Mike Vizard, Chief Content Officer at Techstrong Group, Maz Tamadon, Director of Product and Solution Marketing at Kasten by Veeam, Frank J. Ohlhorst, Editor at Large, Mostafa Radwan, Principal at Road Clouds, Alex Nauda, CTO at Nobl9, joined me, co-chair of the CNCF Cartografos Working Group and VP at Fairwinds covered a lot of them! Read the first six questions, which covered provisioning, frameworks for using Kubernetes, getting started, and how platform teams and DevOps work together. The next post explored Day One, Two, and Three operations, deploying stateful apps, moving apps to Kubernetes, managed services, and how artificial intelligence and machine learning fit into Kubernetes. For this final post, we discuss Kubernetes security, platform engineering, and different distribution options in Kubernetes. Let’s dive in.
When you look at how Kubernetes is being deployed and how rapidly teams are pushing it out there, there is an increased attack surface. Combined with how quickly Kubernetes and other components in the K8s ecosystem are evolving, it's clear that there may be emerging cyber issues that impact applications and services deployed on Kubernetes infrastructure. If you take a DevSecOps approach, you can implement security checks into your continuous integration and deployment pipelines. It’s critical to be able to manage and test the deployments, as well as look at potential security issues. As Kubernetes evolves, it’s important to automate and integrate security into the infrastructure.
At large enterprises, dev, sec, and ops teams may still be very siloed. Development teams may be ready to roll out Kubernetes and security teams may not be very involved yet. One way to address this is for DevOps teams to build in security checks along the way so they can show security teams how they are checking for misconfigurations, identifying vulnerabilities, and fixing issues. There must also be evidence that documents the actions taken to meet regulatory requirements as well.
At the end of the day, you need to protect your apps and services. Unfortunately, Kubernetes is not secure by default, so even if you have other tools in place to secure your environment, you still must provision correctly with the right permissions. Configuring Kubernetes correctly is important for overall security.
The Cloud Native Computing Foundation publishes and updates a white paper on security that provides a great starting point for teams new to Kubernetes security. The four Cs of cloud native security include:
If your Kubernetes team has tools available, open source or commercial, and are following best practices for those four Cs, you will be in decent shape for building secure platforms and applications. In multi-cluster environments, you also need to scan against Kubernetes security best practices to ensure consistent security across multiple teams, clusters, and tenancies.
Organizations that are just getting started with Kubernetes don't need a platform team — yet. When you are reaching or planning for Kubernetes enterprise adoption, however, you need ways to handle compliance and security and work with other different business units. If you have hundreds or thousands of clusters across the organization, each with its own configuration and security vulnerabilities, it makes sense to invest in building a platform team to standardize cluster configuration across the organization. Platform engineering teams need to provide devs with a toolset that includes built-in Kubernetes governance to enforce development best practices rather than requiring those teams to understand everything about Kubernetes.
Organizations want to increase value, lower costs, and minimize risk. Platform engineering teams using Kubernetes play a significant role, enabling them to:
To achieve this, platform engineering teams must configure Kubernetes with security and cost in mind. As the size of the Kubernetes environment increases, managing more people, enabling developers to self-service, and assuring compliance with best practices and internal policies becomes more difficult. As organizations grow their usage of Kubernetes, platform engineers can enable that growth by putting tools in place to automatically enforce best practices.
In Kubernetes, as with many other major software releases, most organizations do not migrate to the latest release immediately. It’s important to see what's happening and how the latest Kubernetes release is running. The latest release almost certainly resolves a lot of security vulnerabilities, however, it’s also important to ensure that it is stable and that other dependencies will continue to function as desired. Organizations should conduct testing of new releases in a pre-production environment to figure out what's working and what's not. If you don’t stay within a few months of the latest release, you will end up with an unsupported environment, however.
Two helpful open source tools you can use when upgrading include Nova, to find outdated or deprecated Helm charts running in your cluster, and Pluto, to find deprecated Kubernetes apiVersions.
Kubernetes is still an evolving technology, but today many enterprise organizations are deploying workloads into production. If your team is committed to implementing Kubernetes and other cloud-native technologies, research cloud native solutions that provide guardrails to help your developers deploy apps and services quickly without putting reliability, security, and cost efficiency at risk.
Attend KubeCrash, a free, virtual, one day event with crash courses in cloud native open source technology to learn more about multi-cluster deployments at scale. Register now athttps://www.kubecrash.io/
