Managed Resource Definitions and Activation Policies

This document is for an unreleased version of Crossplane.

This document applies to the Crossplane master branch and not to the latest release v1.20.

This guide shows how to use Managed Resource Definitions (MRDs) and activation policies to control which managed resources are available in your cluster. You install a provider, examine its MRDs, and use policies to activate only the resources you need.

Tip

This guide demonstrates the performance and discovery benefits of MRDs by working with a subset of AWS resources rather than installing hundreds of CRDs.

By the end of this guide, you understand how to:

Examine MRDs created by provider packages
Use activation policies to control resource availability
Discover connection details through MRD schemas
Optimize cluster performance by activating only needed resources

Prerequisites

This guide requires:

A Kubernetes cluster with at least 2 GB of RAM
Crossplane v2.0+ installed on the cluster
kubectl configured to access your cluster

Understand the default activation policy

Before installing providers, it’s important to understand Crossplane’s default activation behavior. Crossplane creates a default ManagedResourceActivationPolicy that, by default, activates all managed resources with a "*" pattern.

Important

The default "*" activation pattern defeats the performance benefits of safe-start by activating all resources. For this tutorial, the guide works with the default behavior, but production setups should use more selective activation.

Check if you have a default activation policy:

1kubectl get mrap crossplane-default-activation-policy -o yaml

You can edit the default activation policy directly:

1# Delete the default policy and restart Crossplane using Helm
2kubectl delete mrap crossplane-default-activation-policy
3helm upgrade crossplane crossplane-stable/crossplane \
4  --set provider.defaultActivations=null \
5  --namespace crossplane-system --reuse-values
6kubectl rollout restart deployment/crossplane -n crossplane-system

Note

Changes to the default policy are permanent. After the policy exists, Crossplane doesn’t change it, even if you change Helm values.

1# Delete the default policy and restart Crossplane to recreate from Helm values
2kubectl delete mrap crossplane-default-activation-policy
3helm upgrade crossplane crossplane-stable/crossplane \
4  --set provider.defaultActivations=null \
5  --namespace crossplane-system --reuse-values
6kubectl rollout restart deployment/crossplane -n crossplane-system

This approach lets you use Helm chart values to control the default policy.

Install a provider with safe-start capability

Now install a provider that supports safe-start. This provider creates MRDs that activation policies control.

1apiVersion: pkg.crossplane.io/v1
2kind: Provider
3metadata:
4  name: provider-aws
5spec:
6  package: xpkg.crossplane.io/crossplane-contrib/provider-aws:v2.0.0

Apply this configuration:

1kubectl apply -f - <<EOF
2apiVersion: pkg.crossplane.io/v1
3kind: Provider
4metadata:
5  name: provider-aws
6spec:
7  package: xpkg.crossplane.io/crossplane-contrib/provider-aws:v2.0.0
8EOF

Wait for the provider to become healthy:

1kubectl get providers

1NAME           INSTALLED   HEALTHY   PACKAGE                                             AGE
2provider-aws   True        True      xpkg.upbound.io/crossplane-contrib/provider-aws   2m

Examine the managed resource definitions

List the MRDs created by the provider:

1kubectl get mrds

The MRD states depend on your default activation policy:

If you kept the default "*" activation pattern:

1NAME                                    STATE      AGE
2buckets.s3.aws.crossplane.io          Active     2m
3instances.ec2.aws.crossplane.io       Active     2m  
4databases.rds.aws.crossplane.io       Active     2m
5clusters.eks.aws.crossplane.io        Active     2m
6# ... many more, all Active

The default policy activates all MRDs, so safe-start providers behave like traditional providers.

If you disabled default activation:

1NAME                                    STATE      AGE
2buckets.s3.aws.crossplane.io          Inactive   2m
3instances.ec2.aws.crossplane.io       Inactive   2m
4databases.rds.aws.crossplane.io       Inactive   2m
5clusters.eks.aws.crossplane.io        Inactive   2m
6# ... many more, all Inactive

This demonstrates true safe-start behavior where resources must be explicitly activated.

Note

For the rest of this tutorial, the guide assumes you have default activation disabled to show selective activation. If you have default activation enabled, the MRDs are already active.

Examine a specific MRD to understand its schema and connection details:

1kubectl get mrd instances.ec2.aws.crossplane.io -o yaml

Look for the connectionDetails section:

 1spec:
 2  connectionDetails:
 3  - description: The public IP address assigned to the instance
 4    name: public_ip
 5    type: string
 6  - description: The private IP address assigned to the instance  
 7    name: private_ip
 8    type: string
 9  - description: The public DNS name assigned to the instance
10    name: public_dns
11    type: string

Verify resource creation behavior

The presence of CRDs depends on whether MRDs are active:

Because MRDs are active due to the default "*" policy, CRDs exist:

1kubectl get crds | grep aws.crossplane.io | wc -l

This shows 100+ CRDs, demonstrating that active MRDs create CRDs.

Because the MRDs are inactive, no CRDs should exist for AWS resources:

1kubectl get crds | grep aws.crossplane.io

This should return no results, demonstrating that inactive MRDs don’t create CRDs in your cluster.

Create an activation policy

Create a ManagedResourceActivationPolicy to activate specific AWS resources:

1apiVersion: apiextensions.crossplane.io/v1alpha1
2kind: ManagedResourceActivationPolicy
3metadata:
4  name: aws-demo-resources
5spec:
6  activations:
7  - instances.ec2.aws.crossplane.io
8  - buckets.s3.aws.crossplane.io
9  - "*.rds.aws.crossplane.io"

Apply the policy:

 1kubectl apply -f - <<EOF
 2apiVersion: apiextensions.crossplane.io/v1alpha1
 3kind: ManagedResourceActivationPolicy
 4metadata:
 5  name: aws-demo-resources
 6spec:
 7  activations:
 8  - instances.ec2.aws.crossplane.io
 9  - buckets.s3.aws.crossplane.io
10  - "*.rds.aws.crossplane.io"
11EOF

This policy activates:

EC2 instances (exact match)
S3 buckets (exact match)
All RDS resources (wildcard match)

Verify activation

Check that the specified MRDs are now active:

1kubectl get mrds instances.ec2.aws.crossplane.io buckets.s3.aws.crossplane.io

1NAME                              STATE    AGE
2instances.ec2.aws.crossplane.io   Active   5m
3buckets.s3.aws.crossplane.io     Active   5m

List all RDS MRDs to see they’re also active:

1kubectl get mrds | grep rds

1NAME                                      STATE    AGE
2clusters.rds.aws.crossplane.io           Active   5m
3databases.rds.aws.crossplane.io          Active   5m
4dbinstances.rds.aws.crossplane.io        Active   5m
5# ... other RDS resources

Verify custom resource definition creation

Now that MRDs are active, CRDs exist:

1kubectl get crds | grep -E "(instances.ec2|buckets.s3|rds)" | head -5

1buckets.s3.aws.crossplane.io                    2024-01-15T10:30:00Z
2clusters.rds.aws.crossplane.io                  2024-01-15T10:30:00Z
3databases.rds.aws.crossplane.io                 2024-01-15T10:30:00Z
4dbinstances.rds.aws.crossplane.io               2024-01-15T10:30:00Z
5instances.ec2.aws.crossplane.io                 2024-01-15T10:30:00Z

Create a managed resource

Now you can create managed resources using the active MRDs. Create an S3 bucket:

1apiVersion: s3.aws.crossplane.io/v1alpha1
2kind: Bucket
3metadata:
4  name: my-demo-bucket
5spec:
6  forProvider:
7    region: us-east-1
8  providerConfigRef:
9    name: default

Note

This example assumes you have AWS credentials configured. See ProviderConfig documentation for authentication setup.

 1kubectl apply -f - <<EOF
 2apiVersion: s3.aws.crossplane.io/v1alpha1
 3kind: Bucket
 4metadata:
 5  name: my-demo-bucket
 6spec:
 7  forProvider:
 8    region: us-east-1
 9  providerConfigRef:
10    name: default
11EOF

Test inactive resources

Try to create a managed resource for an inactive MRD, like EKS clusters:

1kubectl get mrd clusters.eks.aws.crossplane.io

1NAME                              STATE      AGE
2clusters.eks.aws.crossplane.io   Inactive   8m

Attempting to create an EKS cluster fails because the CRD doesn’t exist:

 1kubectl apply -f - <<EOF
 2apiVersion: eks.aws.crossplane.io/v1alpha1
 3kind: Cluster
 4metadata:
 5  name: test-cluster
 6spec:
 7  forProvider:
 8    region: us-east-1
 9    version: "1.21"
10EOF

1error validating data: ValidationError(Cluster): unknown field "apiVersion" in io.k8s.api.core.v1.Cluster

Expand activation with wildcards

Add more resources using wildcard patterns. Update your activation policy:

 1kubectl patch mrap aws-demo-resources --type merge -p '{
 2  "spec": {
 3    "activations": [
 4      "instances.ec2.aws.crossplane.io",
 5      "buckets.s3.aws.crossplane.io", 
 6      "*.rds.aws.crossplane.io",
 7      "*.eks.aws.crossplane.io"
 8    ]
 9  }
10}'

Verify EKS resources are now active:

1kubectl get mrds | grep eks

1NAME                                STATE    AGE
2clusters.eks.aws.crossplane.io     Active   10m
3nodegroups.eks.aws.crossplane.io   Active   10m

Examine activation policy status

Check which MRDs your policy has activated:

1kubectl get mrap aws-demo-resources -o yaml

Look for the status.activated field:

1status:
2  activated:
3  - buckets.s3.aws.crossplane.io
4  - instances.ec2.aws.crossplane.io
5  - clusters.rds.aws.crossplane.io
6  - databases.rds.aws.crossplane.io
7  - clusters.eks.aws.crossplane.io
8  - nodegroups.eks.aws.crossplane.io
9  # ... other activated MRDs

Performance comparison

Compare the resource usage with traditional provider installation:

Without MRDs (traditional):

All ~200 AWS CRDs created when provider installs
Higher memory usage in kube-apiserver
Longer provider installation time

With MRDs and selective activation:

Only activated CRDs created (10 to 20 in this example)
Lower memory footprint
Faster resource discovery and management

Check the number of AWS CRDs in your cluster:

1kubectl get crds | grep aws.crossplane.io | wc -l

This should be much smaller than the total number of MRDs.

Multiple activation policies

You can create multiple MRAPs for different use cases. Create a second policy for development environments:

 1kubectl apply -f - <<EOF
 2apiVersion: apiextensions.crossplane.io/v1alpha1
 3kind: ManagedResourceActivationPolicy
 4metadata:
 5  name: aws-dev-resources
 6spec:
 7  activations:
 8  - "*.ec2.aws.crossplane.io"
 9  - "*.iam.aws.crossplane.io"
10EOF

Both policies combine their activations, giving you fine-grained control over resource availability.

Clean up

Remove the demo resources:

1kubectl delete bucket my-demo-bucket
2kubectl delete mrap aws-demo-resources aws-dev-resources
3kubectl delete provider provider-aws

Production recommendations

For production Crossplane deployments, follow these best practices:

1. Disable default activation

Install Crossplane with selective activation:

1helm install crossplane crossplane-stable/crossplane \
2  --set provider.defaultActivations=null \
3  --namespace crossplane-system

2. Use targeted activation policies

Create provider-specific policies rather than using the default "*" pattern:

 1apiVersion: apiextensions.crossplane.io/v1alpha1
 2kind: ManagedResourceActivationPolicy
 3metadata:
 4  name: production-aws-resources
 5spec:
 6  activations:
 7  - "instances.ec2.aws.crossplane.io"
 8  - "*.rds.aws.crossplane.io"
 9  - "buckets.s3.aws.crossplane.io"
10  - "*.iam.aws.crossplane.io"

3. Environment-specific policies

Use different activation strategies per environment:

Development: Broad activation for experimentation
Staging: Subset of production resources for testing
Production: Minimal, specific activation for performance

Next steps

Now that you understand MRDs and activation policies, you can:

Optimize cluster performance by using selective activation
Improve resource discovery through MRD connection details documentation
Implement environment-specific policies for different deployment stages
Plan provider adoption using safe-start-capable providers

Learn more about: