Jan 20, 2021
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
This article analyzes a few different security domains and how Kube360
provides a security focus out of the box.
Federated authentication
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:
Create a single service account with full permissions on the cluster
Generate a kubeconfig file for that service account
Share that file with all developers and operators
Paste that kubeconfig file into secrets configuration for CI scripts
The default configuration of Kubernetes, unfortunately, makes this kind
of setup enticingly inviting. In exchange for simplicity, teams are
trapped with many weaknesses:
This kubeconfig file becomes a single point of failure for compromising the entire cluster
Migrating clusters is a painful and laborious experience
It is all too easy to grant too many permissions to a user or CI job, leading to accidental breakage
Offboarding a staff member is difficult and dangerous
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.
Role-based authorization
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.
Namespacing and isolation
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.
Encryption in transit
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.
Conclusion
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.