 Hello and welcome to this talk about Least Privilege Cloud Service Provisioning with Crossplane. Today we're going to cover what is Least Privilege technically, the risks, challenges and some of the mitigations in the crossplane product in this space and some takeaways. 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 is Lewis Marshall. I'm a senior developer and tech evangelist at Apia. I have 30 years of tech experience. I'm a bit old. I started my career with 886 Sembler and nowadays I code in Golang and I've been lucky enough to be involved with Apia and the Kubernetes project right from the start. So what is Least Privilege? Least 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. 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. What are the risks? Well, there's too much to talk about loads of different risk vectors. We've only got 10 minutes. It's a lightning talk so let's get on again and talk about risks in the general sense. Here we have a castle with many, many, many fortifications. Risks are real and a serious threat to any business, specifically in this space around overprivileged and privilege escalation, but they're not. Solutions in isolation defend in depth like the castle is the contacts here. So challenges. 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-plane 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. 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. We are defining resources and managing cross-plane providers. What does that look like? 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're highly specific. They only work in the cloud. The limitations is that you've got to install cross-plane on a cloud provider, and today that means only on Amazon with EKS using this capability of injected identity. Now the community is already cognizant of this and have the issues against the other providers to bring this capability up to date across cross-plane. We also want specifically scoped access. We want to stop default access or root access, where we have one provider config. The risk here is around preventing accidental or malicious exploits, and here we have access to IAM provisioning, which means we can provision backdoors and inappropriate access to our cloud accounts. If we use scoped provider configs for each resource type, we can mitigate and remove this particular issue. Here we have multiple provider configs for each resource type. What's that look 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. Now there's a challenge here with injected identity, so I want to cover that. Scoped access issue with the pod's 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. If we add an assumed role ARN to that provider configuration resource for Amazon, we would bring that capability. I've created an issue upstream for provider AWS there to have that capability and a similar issue using service accounts with delegation in GCP and a relatable issue about using workload identity for pods. 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, wherever permissions are granted for their use and not for an installation. It stops the proliferation of additional credentials and less things to manage and gives us shortest lived access where applicable. Now, we also want to simplify this scoped access. I've created this issue for cross-plane and the Kubernetes Cube CTR plugin to simplify the ability to audit and understand the permissions of cross-plane resources. 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. I've also created an issue on the Azure provider to bring that into line with this direction. If we have this capability across providers by having a standardized way of doing this, then we can have that centralized capability. 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. Please comment, like, and share these issues. If you're interested in how we are at VR using cross-plane in our multi-cloud core developer platform, then please visit us at app.io. Thank you very much for your time today.