IBM Cloud Kubernetes Services: Optimised Cluster and App Security in the Cloud
Containerisation has revolutionised workload deployment across the cloud.
It allows applications to seamlessly flow, quickly, reliably and securely, from one computing environment to another.
It’s a system that comes with inbuilt security: and yet malicious attackers are constantly seeking out weak spots in any defence.
An MSP Cloud’s unencrypted worker nodes could present an opportunity to the more innovative cybercriminals.
Which is why IBM Cloud Kubernetes Services encrypt all worker nodes as a default.
Cloud Hosting with Optimised Security
The built-in security features of IBM Cloud Kubernetes Services provide isolation, resource management capabilities, and worker node security compliance.
Containerised apps run in pods that are hosted on compute hosts called worker nodes.
Each worker node is a physical machine (bare metal) or a virtual machine that runs on physical hardware in the cloud environment.
By default, IBM Cloud Kubernetes Services ensures that every worker node is provisioned with two local SSD, AES 256-bit encrypted data partitions.
To be more specific, the first partition contains the unencrypted kernel image that is used to boot the worker node.
The second partition, however, holds the container file system and can only be unlocked by using LUKS encryption keys.
Each worker node in a cluster has its own unique LUKS encryption key.
When you create a cluster, or add a worker node to an existing cluster, the keys are pulled securely and then discarded after the encrypted disk is unlocked.
Of course, encryption can impact disk I/O performance.
And so for workloads requiring high-performance disk I/O, you can test a cluster with encryption that is either enabled or disabled, helping you decide if you wish to turn encryption off.
Kubernetes VS Docker: why not use both?
The question of Kubernetes VS Docker doesn’t arise with IBM Cloud Kubernetes Services as it combines both to deliver the most powerful and innovative tools.
Docker’s open-source lightweight containerisation technology enables the automation of the deployment of applications in lightweight and portable containers, while allowing multiple operating systems to run on the same host.
Kubernetes’ highly flexible open-source container management software empowers the delivery of even complex containerised applications, running on clusters of thousands of individual servers to ensure efficient management across various types of physical, virtual, and cloud environments.
Protecting Sensitive Information in Clusters and Apps
To ensure data integrity and prevent it from being exposed to unauthorised users, sensitive data can be created on different levels in your cluster to enable appropriate protection.
On the App Level, as a security consideration, confidential information like credentials, keys, configmaps, or scripts aren’t simply stored on a server when an app is deployed.
Unauthorised users are prevented from accessing private information by Kubernetes Secrets, a secure way to store details such as usernames, passwords, or keys that allows you to encrypt important data.
On the Cluster Level, configuration data is stored in the etcd component Kubernetes master’s local disk.
The etcd is a distributed key-value store which is highly available, strongly consistent, and watchable for changes. And, having been encrypted during transit, the data is backed up to IBM Cloud Object Storage.
By accessing IBM Key Protect for your cluster, you can enable encryption of your etcd data stored on your Kubernetes master’s local disk.
(The etcd data for clusters running on earlier versions of Kubernetes is stored on an encrypted disk managed and backed up daily by IBM.)
Container Isolation and Security
When running multiple apps in your cluster, you need to make sure that the workloads run in isolation from each other.
You also need to restrict the permissions of your pods within the cluster to avoid eavesdroppers or denial-of-service attacks.
Kubernetes Namespaces can be used to virtually partition a cluster, providing isolation for your deployments and the user-groups wanting to move their workloads onto the cluster.
Using namespaces, you can organise resources across worker nodes, as well as across zones in multizone clusters.
Every cluster comes with a set of default Kubernetes Namespaces that include the deployments and services required to run and manage the cluster efficiently.
Cluster administrators are automatically granted access to these Namespaces, and can set up additional Namespaces within the cluster.
Just make sure that every namespace you have in the cluster is set up with the required RBAC policies limiting access to it, along with deployment controls, resource quotas, and range limitations.
Get started today – for free, for 1 year
IBM Cloud Kubernetes Service provides simplified cluster management, built-in security and isolation, all in a cloud-native, open-source environment.
Wouldn’t you like to streamline your cloud operations while delivering value to your customers?
Then start your 1-year free trial of Cloud Kubernetes Services by clicking here.
After the 1-year trial, you can either upgrade to the subscription plan or chose to pay only for what you use on a PAYGO basis.