Is a Multi-Cloud Strategy Safe? Here’s What You Need to Know

Is a Multi-Cloud Strategy Safe? Here’s What You Need to Know

Now that cloud adoption has gained traction in most organizations, there are fewer conversations about whether migrating processes and workloads to the cloud is necessary. The accessibility, collaboration, and scalability of these tools has transformed the business world. However, every cloud vendor has different strengths and weaknesses, encouraging many innovators to explore ways to maximize the benefits of multiple cloud platforms.

Simply put, multi-cloud and hybrid cloud are deployment models that integrate more than one cloud. Multi-cloud strategies involve multiple providers of public cloud services (e.g., AWS, Microsoft Azure, Google Cloud Platform, etc.), each of which is responsible for a specific workload. Hybrid cloud setups, on the other hand, feature at least one private cloud or on-prem data center and one public cloud. The former solution appears more modern and streamlined on paper. Adoption of multi-cloud solutions also can’t be ignored, as 81% of public cloud users reported they were using the services of multiple cloud vendors, according to a 2020 Gartner survey.

But the question remains: is a multi-cloud strategy safe for your business? The short answer is “yes,” but there are considerations you should understand before implementing. Here’s what you need to know.

Shields Up Guidance for All Organizations

Shields Up Guidance for All Organizations

What is happening?

The Russian government has used cyber as a key component of their force projection over the last decade, including previously in Ukraine in the 2015 timeframe. The Russian government understands that disabling or destroying critical infrastructure—including power and communications—can augment pressure on a country’s government, military, and population, accelerating their acceding to Russian objectives.

While there are not currently any specific credible threats to the U.S. homeland, the potential exists for the Russian government to consider escalating its destabilizing actions in ways that may impact others outside of Ukraine.

Hands-on with Kubernetes Pod Security Policies

Kubernetes Pod Security Policies allow you to control the security specifications that pods must adhere to in order to run in your cluster. You can block users from deploying inherently insecure pods either intentionally or unintentionally. This sounds like a great feature and a security best practice and can be a big step toward keeping your cluster free of insecure resources.

However, some pods may require additional security permissions beyond what most cluster users are allowed to deploy. For example, monitoring or metrics tooling may need host network access or may need to run in privileged mode. Also, you may need to allow developers to run applications with additional capabilities during early development stages just to make progress.

How hard is it to use Pod Security Policies to judiciously secure your cluster? We’ll look at that in this blog post.

Who Can…?

Managing a Kubernetes cluster with one user is easy. Once you go beyond one user, you need to start using Role-Based Access Control (RBAC). I’ve delved into this topic several times in the past with posts on how to Create a Kubernetes User Sandbox in Docker Enterprise and Functional Kubernetes Namespaces in Docker Enterprise. But, once you get beyond a couple of users and/or teams and a few namespaces for them, it quickly becomes difficult to keep track of who can do what and where. And, as time goes on and more and more people have a hand in setting up your RBAC, it can get even more confusing. You can and should have your RBAC resource definitions in source control but it’s not easy to read and is hard to visualize. Enter the open source who-can kubectl plugin from the folks at Aqua Security. It gives you the ability to show who (subjects) can do what (verbs) to what (resources) and where (namespaces).