Security is a multifaceted concept with broad-reaching applications across multiple domains. As a complete server deployment solution, Kube360 touches on many different pieces of the security puzzle. FP Complete has years of experience helping our clients boost Kubernetes security with Kubernetes in particular and cloud deployments in general. We’ve accumulated many of our learned best practices and included them as sensible and secure defaults in Kube360.
This article analyzes a few different security domains and how Kube360 provides a security focus out of the box.
One of the primary Kubernetes security weaknesses we regularly see in Kubernetes installations is user authentication. The most common approach to connecting to a cluster seems to be:
The default configuration of Kubernetes, unfortunately, makes this kind of setup enticingly inviting. In exchange for simplicity, teams are trapped with many weaknesses:
In Kube360, we’ve deployed federated authentication out of the box. Kube360 is configured to work with your originating directory service by default. Virtually all popular platforms—including Microsoft 365, Google, and Okta—are supported. Instead of maintaining yet another set of credentials, users can reuse their existing accounts, complete with two-factor authentication and other deterrents to intrusion.
Credentials in Kube360 are also short-lived. Instead of receiving a permanent kubeconfig file, Kube360 ships with web-based and command-line tooling for issuing and updating temporary credentials. This follows Kubernetes security best practices and minimizes the impact of security breaches. When combined with the central directory, offboarded staff will quickly and automatically lose access to the cluster.
And finally, by leveraging existing authentication systems, we believe Kube360 can democratize operations. The deployment systems and dashboards are often a complete black box to anyone outside of the engineering organization. With federated login, every team member—from CEO to sysadmin—can easily access the cluster and gain insight.
The final piece of the puzzle is role-based authorization. Kube360 ties together directory service groups, such as Microsoft 365 security groups, with Kubernetes’s RBAC system. By defining a group to role mapping and providing a limited set of permissions for each role, users can be granted access to only the systems they need. View-only permissions, single-namespace permissions, and more can be granted to various teams. And our customized dashboard views allow for an integrated experience for every member of the team.
Kube360 encourages multitenancy within an organization. Instead of separating out various applications into separate clusters, we encourage hosting multiple applications within a single cluster. We also recommend hosting the development, staging, QA, and production environments within the same environment. This reduces hardware costs, simplifies operations, and provides a unified insight into what the organization is running.
This kind of multitenancy does introduce security concerns. Done poorly, multitenancy can allow one application to accidentally intrude upon another via network traffic or by leveraging shared Kubernetes resources, especially secrets. This can elevate a security intrusion into one application to a cluster-wide compromise.
Kube360 encourages the isolation of applications by default. We recommend and provide tooling and documentation around a namespace-driven isolation strategy. This allows segmenting of the network traffic between applications, restrict access to users via RBAC rules, and minimally advertising secret data across the cluster.
Combined with our central application visualization tooling via ArgoCD, namespacing is simple, natural, easy to work with, and a sensible default.
Increasingly, organizations and regulators are insisting on encrypting all network traffic. Load balancers with TLS termination solve the external traffic issue with minimal application impact. Kube360 provides both external-DNS and cert-manager to automate the acquisition and usage of TLS certificates, making it trivial to ensure all incoming connections are properly encrypted.
But intra-cluster traffic encryption is typically an invasive, time consuming, and error-prone activity. To address this, Kube360 ships with Istio service mesh out of the box. By default, every pod launched into a Kube360 cluster will have an Istio sidecar responsible for encrypting network traffic. Not only will incoming traffic from the outside world be encrypted when hitting the cluster, but traffic from the load balancer to the pods and in between pods in a microservices architecture will all be encrypted.
Encryption is handled via mutual TLS (mTLS). By default, traffic in different namespaces leverages separate keys for additional isolation.
Modern organizations are under enormous pressure to ship features and answer user demands. The unfortunate reality is that security often takes a back seat. Modern DevOps tooling and cloud services can be a boon to productivity. But insecure defaults can lead to weaknesses.
We’ve given you a small taste of what we’ve done in Kube360 to strengthen tooling by default. Our tooling works hand in hand with your engineers to create a multifaceted, multilayered approach to security, which will protect your services, your customers, and your organization.
If you’d like to learn about other security features within Kube360, please contact us to set up a consultation with our engineering team to explore how Kube360 can help you.
Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.
