Cloud Native Computing Foundation Crossplane Community Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Secure, Least Privilege Cloud Service provisioning with Crossplane - Lewis Marshall

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: Secure, Least Privilege Cloud Service provisioning with Crossplane - Lewis Marshall, Appvia Ltd

Providing production ready and secure cloud services for applications, whether that’s a database, cache, or object store is more of a challenge than just provisioning. Security and resilience is essential for application teams to deliver lasting business value. Crossplane provides a self service developer capability but challenges exist around ensuring secure and suitably scoped cloud service provisioning. We’ve investigated “least privilege” for Crossplane resource provisioning. We uncover how to enable the best practice of cloud managed identities with Crossplane with appropriately secure access. Through collaboration with large organisations and a desire to contribute to the Crossplane community, we aim to enable developer self service with maximum security.

A

Hello and welcome to this talk about least privileged cloud service provisioning with crossplane.

A

Today, we're going to cover what is least privileged technically the risks challenges and some of the mitigations in the crossplane product in this space and some takeaways, and it's a lightning talk, so I better get on with it a little bit about myself. If I may, before I start my name's louis marshall, I'm a senior developer and tech evangelist at appvia. I have 30 years of tech experience, I'm a bit old.

A

I started my career with 886 assembler and nowadays I code in golang and I've been lucky enough to be involved with appvia and the kubernetes project right from the start.

A

So what is least privilege this privilege is the principle of granting only the permissions required to complete the task. I found this quote from amazon, which seemed quite succinct, but what is it a little bit more specifically, it's specific access, it's task related, and it's not general otherwise known as root a picture of root. Here we don't want that permission. We want the permission right at the top. That's highly specific.

A

We also want to have it even more specific if we can, by having it time, limited short-lived and the capability to audit. When we use that access, we don't want stored credentials either, because by definition they are the very longest lived type of access.

A

What are the risks? Well, there's too much to talk about loads of different risk factors, so we've only got 10 minutes. It's a lightning talk. So let's get on again and talk about this in the general sense. Here we have a castle with many many many fortifications.

A

Risks are real and a serious threat to any business, specifically in this space around over privilege and privilege escalation, but they're, not solutions in isolation. Defense in depth, like the castle, is the context here so challenges.

A

Historically, there used to be real people trusted employers and the tools focused around that with two-factor authentication and short-lived interactive user flows. This isn't really applicable these days with cross-plain and resource reconciliation without a man directly in the loop at the time of provisioning. There's also other challenges around complexity. It's hard work to audit the code of any provisioning tool, including cross plane. This affects velocity our ability to deliver business value quickly, and we want to be able to discover and fail early.

A

So what are the cross-plane mitigations? We don't want to look at developer flow and application access, although they do pertain to this area. We've only got 10 minutes, so we want to concentrate on the infrastructure operator perspective and we are defining resources and managing cost plane providers.

A

What does that look like um here? We have a provider configuration in cross plane. We want to look at the first issue around how we can use cloud managed access credentials that are automatically provided and managed by a cloud provider. The benefits are that we're not storing any credentials and they can be short-lived, but they are highly specific. They only work in the cloud.

A

The limitations is that you've got to install crossplane on a cloud provider, and today that means only on amazon, with eks, using this capability of injected identity.

A

Now the community is already cognizant of this and have the issues against the other providers to bring this capability up to date across cosplay.

A

We also want specifically scoped access. We want to stop default access or route access where we have one provider config. The risk here is around preventing accidental or malicious exploits, and here we have access to. I am provisioning, which means we can provision back doors and inappropriate access to our cloud accounts.

A

So if we use scoped provider configs for each resource type, we can mitigate and remove this particular issue. And here we have multiple provider conflicts for each resource type.

A

What's that looked like in the resource type definitions for cross plane, we have a specific type of resource, an rds instance here, looking at a specific aws rds configuration.

A

Now, there's a challenge here with injected identity, so I want to cover that scoped access issue with the pods identity. We have the amazon provider running as a pod in kubernetes eks, in this case, with a service account that is linked to that amazon identity, which kind of describes a single provider config with that single identity using injected identity. What we want is multiple provider configs with multiple specific access at the point of provisioning and if we add an assume role, arn to that provider configuration resource for amazon, we would bring that capability.

A

So I've created an issue upstream for provider aws there to have that capability and a similar issue using service accounts in with delegation in gcp and a relatable issue about using workload, identity, footpods in as in and together. This gives the ability to manage access with new resources and not the installation of cross plane, which also gives us the added benefit of an improved audit capability, whether permissions are granted for their use and not in for an installation.

A

It stops the proliferation of additional credentials and less things to manage and gives as as lived access where applicable.

A

Now we also want to simplify this scoped access, so I've created this issue for cosplaying and the kubernetes cube ctr plug-in to simplify the ability to audit and understand the permissions of cosplaying resources, and the community was already ahead of me when I was thinking in this area by looking at how they can do static analysis of the code to annotate the resources published such that they have that permission information.

A

I've also created an issue on the azure provider to bring that into line with this direction, and if we have this capability across providers by having a standardized way of doing this, then we can have that centralized capability.

A

So a little bit about the takeaways. If we have scoped access with short-lived and managed credentials, we simplify that access management. We can update and improve cross-plane experience for security.

A

Please comment like and share these issues and, if you're interested in how we at vr using cosplay in our multi-cloud core, operate developer platform, then please visit us at apio and thank you very much for your time today.