Enhancing Security Practices with Crossplane Providers

This time last year Upbound released their first "Official Providers" providing improved performance, resource coverage and testing for Crossplane providers.

In June of this year Upbound made greater improvements to the Providers with our "Provider Families", logically grouping resources from a provider into a single unit, dramatically reducing the size and scale of the Provider resources required for users to run their Crossplane control planes.

Last month the Crossplane steering committee decided to make changes to the Crossplane charter, adding Providers to the scope of the Crossplane project. Along with this change, Upbound donated their "Official Providers" to the Crossplane project, making them fully open source and under the governance of the CNCF.

More Providers, more open source capabilities, and more overall capabilities are great, but it doesn't help much when users can't access their cloud providers in a way that meets corporate security requirements.

Users spoke, docs listened. Confusion and complexity around Provider authentication comes up time and again in the Crossplane Slack channel. The docs team took the time to walk through every authentication method for Provider AWS, Provider Azure and Provider GCP to make authentication easier. This includes not only basic key-based authentication but more advanced authentication methods for users of managed Kubernetes services. Just as the Providers are moving from Upbound to Crossplane, we'll see the same thing happen with these new Provider docs.

Authentication with Provider AWS

Our updated documentation covers classic AWS access keys and for EKS users AssumeRoleWithWebIdentity and IAM roles for service accounts, also called IRSA.

Using AWS web identity allows users running Crossplane inside EKS to authenticate using an AWS OIDC provider and use AWS IAM "assume role" to elevate the permissions of the Crossplane pod when requesting AWS services.

Another option for users running Crossplane inside EKS is IRSA. Crossplane relies on credentials generated by EKS and automatically attached to the Crossplane pod. There are no keys to maintain and rotate or user lists to update.

Authentication with Provider Azure

The Provider Azure authentication docs now include details for Azure managed Kubernetes users running Crossplane in AKS.

System-assigned managed identity uses credentials generated by Azure and tied directly to the AKS cluster to authenticate Crossplane. Similar to AWS IRSA, this means no usernames or passwords to manage, secure or update.

User-assigned managed identity goes even further, for organizations using a single identity across multiple resources.

Authentication with Provider GCP

Provider GCP authentication docs detail how to use OAuth 2.0 access tokens, Service account impersonation and Workload Identity, for users running Crossplane inside GKE.

OAuth access tokens allows Crossplane to use short-lived keys for authentication. Some users are automatically generating and updating keys and providing them to the Crossplane to increase security over static keys with long or infinite lifetimes.

Other users rely on Service account impersonation to allow for temporary privilege escalations for the Crossplane pod. This allows the Crossplane pod to run with lower permissions and only allow specific Compositions or Claims to access restricted resources. This is a great way for a single Crossplane deployment to provide multiple different security levels across users.

For GKE users they can use Workload Identity to restrict access to GCP resources to only the Crossplane pod running inside GKE. Users don't have to worry about keys or credentials leaking since only resource requests from inside the GKE cluster can request resources. Crossplane, running in GKE, can now use workload identity as an authentication method.

Provider Docs - Just the Beginning

Over the last year the team has put a lot of energy into improving the overall Crossplane documentation. There's still more to do, but we're proud of the work so far, and the feedback has indicated we're working on the right things.

But now we're hearing and feeling the challenges first hand with documentation for the core Crossplane API types, Provider API types and usage examples.

It's not going to be a simple project but we're putting our focus on it. We're working on some tooling to update and publish API docs that will work for both Crossplane and Providers and we think will work for your custom XRD APIs as well. Stay tuned, we'll be sure to tell you more when it's ready.
In the meantime, check out our the new Provider documentation and get started with Crossplane!