Overview of IBM Cloud & Kubernetes Security

One of the ways in which IBM aims to stand out in the cloud computing market, where it remains a minority player, is by focusing on flexibility and customizability.

That’s great from a marketing perspective. But from a security perspective, more potential configurations means more challenges – which is why learning to secure IBM Cloud environments is essential for leveraging IBM’s cloud services successfully, whether you use them on their own or as part of a broader multicloud or hybrid cloud strategy.

To be clear, security challenges are a major consideration on any cloud platform, not just IBM’s. But IBM’s commitment to flexibility in its cloud services and configurations makes it especially challenging to manage security risks associated with diverse cloud architectures and setups.

In this article, we explain how to secure workloads running on IBM Cloud. Specifically, we discuss IBM’s approach to the shared responsibility model, common security mistakes in IBM Cloud, best practices for securing IBM Cloud and how to secure and monitor IBM Cloud Kubernetes Service, one of IBM’s key cloud platforms.

IBM Shared Responsibility Model

Like all public cloud providers, IBM Cloud uses a shared responsibility model that defines which security and compliance responsibilities are managed by IBM Cloud, and which ones lie with customers.

IBM offers a very detailed breakdown of security responsibilities, which you can consult if you want all of the details on IBM’s shared responsibility architecture. In general, however, the policies boil down to the following:

• Customers are responsible for securing all applications and data that they deploy or run on IBM Cloud, including those hosted via managed IBM services (like IBM Cloud Kubernetes Service).
• IBM is responsible for securing the physical networks and servers that power its cloud (although, as noted below, customers are responsible for securing bare-metal servers deployed in IBM Cloud).
• Responsibility for securing most types of virtualized resources – such as virtual servers and virtual networks – is shared between IBM and customers. IBM handles security for the virtualization components (like hypervisors) that customers don’t control, while customers must secure resources like the operating system that they choose to install on virtual machines.

IBM Cloud Security Mistakes to Avoid

Again, at a very high level, the main security challenge in IBM Cloud is that, because IBM gives customers so many different ways to configure and deploy workloads, following security best practices is complex. When you are working with cloud environments that can be designed and configured in a wide variety of ways, there is no simple set of rules to follow.

So, it perhaps makes the most sense to think about what not to do from a security perspective when designing and configuring IBM Cloud workloads. The following are some common IBM Cloud security mistakes to avoid.

Don’t Overlook Bare-Metal Server Security Needs

One of the ways in which IBM Cloud aims to offer more choice than competing clouds is by providing a wide selection of bare-metal IaaS server instances. Bare-metal cloud servers typically offer better performance than virtual servers because customers don’t have to share an underlying physical machine with other users.

Where you can go wrong from a security perspective with bare-metal servers, however, is assuming IBM manages server security for you. While it’s true that, in general, most of the physical infrastructure in IBM Cloud is secured by IBM, bare-metal server instances are an exception. Because customers deploy these instances and provision them with the operating system and applications they wish to run, customers take primary responsibility for securing bare-metal servers. IBM provides physical security, but most other security responsibilities lie with customers.

Don’t Forget to Secure Managed Services

IBM Cloud offers a number of managed cloud services, ranging from a hosted implementation of Tekton, a CI/CD platform, to managed Hadoop, to its various Cloud Pak automation and analytics services.

As with bare-metal server instances, IBM Cloud’s managed services can be challenging from a security perspective because it can be tempting for customers to assume IBM handles more security responsibilities than it does. Although IBM secures the underlying infrastructure powering its managed services, as well as any SaaS applications and APIs IBM provides as part of the services, IBM doesn’t secure applications or data customers choose to deploy using one of these managed services.

Thus, if you upload sensitive data into IBM Analytics Engine, for example, or you deploy your own applications inside containers on IBM Cloud Kubernetes Service, responsibility for securing that data and those applications lies with you. IBM won’t anonymize your data for you or scan your container images for vulnerabilities. That’s your job.

Don’t Configure IAM Ineffectively

As is the case with any cloud, workloads hosted on IBM Cloud are only as secure as the Identity and Access Management (IAM) policies that govern them.

IBM Cloud provides an IAM framework that customers can use to manage permissions via the cloud console, CLI, or API. IAM rules should be configured that enforce the principle of least privilege for all resources running in an IBM Cloud environment.

For example, the following IBM cloud access policy grants the user “IBMid-3IAMISBEST1” access privileges to resources that have the following characteristics:

• They are in the resource group “default.”
• They have an ID of “abcd2e6fg1h74i44j5kl467m701n5289.”
• They have the “Viewer” platform role assigned.

{
"type": "access",
"subjects": [
{
"attributes": [
{
"name": "iam_id",
"value": "IBMid-3IAMISBEST1"
}
]
}
],
"roles": [
{
"role_id": "crn:v1:bluemix:public:iam::::role:Viewer"
}
],
"resources": [
{
"attributes": [
{
"name": "accountId",
"value": "7e522a19eb77477e88e96a600c44fb22"
},
{
"name": "resourceGroupId",
"value": "abcd2e6fg1h74i44j5kl467m701n5289"
}
]
}
]
}Code language: JSON / JSON with Comments (json)

In general, IAM roles like these are similar to those you would define on other clouds. However, note that IBM Cloud IAM works a little differently from other cloud providers’ IAM frameworks. For example, users are managed via external tools rather than being defined in IAM, as is the case with AWS IAM. You’ll want to read through IBM Cloud’s IAM docs to understand its unique approach to IAM, then, before you begin writing IAM policies for your workloads.

Don’t Rely on IBM Security Monitoring and Alerts Alone

IBM Cloud provides some native security tools. The most notable is IBM Cloud Security Advisor, which provides an overview of potential security issues IBM has identified in your cloud environments. The insights are based largely on security monitoring configurations defined by IBM, but you can create custom rules as well.

Cloud Security Advisor is a useful starting point for IBM Cloud security monitoring, but it’s typically not sufficient on its own for complete security monitoring for two reasons. One is that it only works with IBM Cloud, which is a problem if you also use other clouds or on-premises environments that are not integrated with your IBM Cloud environment. The second is that Cloud Security Advisor isn’t always able to detect highly nuanced or specific types of security threats, such as those that may exist in a complex Kubernetes environment.

Securing IBM Cloud Kubernetes Service

Because IBM Cloud Kubernetes Service has emerged as a major managed Kubernetes offering that can compete with the likes of Amazon Elastic Kubernetes Service or Google Kubernetes Engine, it’s worth saying a few words about securing IBM Cloud Kubernetes Service in particular as part of a broader IBM Cloud security strategy.

Because IBM Cloud Kubernetes Service is a managed service, IBM handles security for the servers that host Kubernetes clusters. It also secures network traffic, and it provides each customer with a dedicated, single-tenant cluster so that security issues that involve other customers’ workloads won’t impact you.

Beyond this, however, most security responsibilities lie with users, including:

• Updates and upgrades: Once a cluster is deployed, users have to update their clusters manually when new versions of Kubernetes appear. (IBM Cloud will notify you if a new version is available.)
• Container image security: You must check for vulnerabilities in containers that you deploy to Kubernetes using container image scanning.
• Kubernetes API security: Using tools like Kubernetes RBAC, customers should mitigate the risks of security abuses involving Kubernetes API.
• Security vulnerability mitigation: Although IBM secures the Kubernetes nodes that form Kubernetes clusters, customers should still take steps to mitigate the risk that a security vulnerability could be exploited by; for example, preventing containers from running in privileged mode and isolating containers at the network level.

In most respects, securing workloads running on IBM Cloud Kubernetes Service is the same as securing any type of Kubernetes environment. The main difference is that IBM secures the underlying server and networking infrastructure. Most other security responsibilities fall to the customer.

Monitor and Audit Your IBM Cloud Workloads

To take full advantage of the special features that IBM Cloud provides, which include a range of managed services as well as an especially broad set of choices surrounding resources like bare-metal server instances, you must know how to secure the workloads that you deploy in IBM Cloud. Tools like IBM Cloud Security Advisor are a start, but most use cases will require additional security monitoring and auditing using third-party tools.