Managed Resource Activation Policies

A ManagedResourceActivationPolicy (MRAP) controls which ManagedResourceDefinitions become active in your cluster. MRAPs enable selective installation of provider resources, allowing you to activate only the 10 managed resources you need instead of the 100+ that a provider ships.

The selective activation problem

Modern Crossplane providers can ship dozens or hundreds of managed resources, but most users only need a small subset. Before MRAPs, you got “all or nothing” - installing a provider meant getting every managed resource it supported, consuming unnecessary cluster resources.

MRAPs solve this by providing pattern-based activation of ManagedResourceDefinitions, letting you choose which provider resources to enable.

How MRAPs work

MRAPs contain activation patterns that match ManagedResourceDefinition names. When you create or update an MRAP, Crossplane:

1. Lists all MRDs in the cluster
2. Matches MRD names against the activation patterns
3. Activates matching MRDs by setting their state to Active
4. Updates the MRAP status with the list of activated resources

1apiVersion: apiextensions.crossplane.io/v1alpha1
2kind: ManagedResourceActivationPolicy
3metadata:
4  name: aws-core-resources
5spec:
6  activate:
7  - buckets.s3.aws.m.crossplane.io      # Modern v2 style S3 buckets
8  - instances.rds.aws.m.crossplane.io   # Modern v2 style RDS instances
9  - "*.ec2.aws.m.crossplane.io"         # All modern v2 style EC2 resources

When you apply this MRAP, Crossplane activates the specified S3 Bucket, RDS Instance, and all EC2 resources, leaving other AWS resources inactive.

Key features

• Pattern-based matching: Use wildcards to activate groups of resources
• Multiple policy support: Different MRAPs can activate different resource sets
• Status tracking: See which resources each policy activated
• Automatic activation: New MRDs matching existing patterns activate automatically

Pattern matching

Exact matching

Specify complete MRD names for precise control:

1spec:
2  activate:
3  - buckets.s3.aws.m.crossplane.io
4  - databases.rds.aws.m.crossplane.io
5  - clusters.eks.aws.m.crossplane.io

Wildcard patterns

Use * wildcards to match multiple resources:

1spec:
2  activate:
3  - "*.s3.aws.m.crossplane.io"      # All S3 resources
4  - "*.ec2.aws.m.crossplane.io"     # All EC2 resources  
5  - "*.rds.aws.m.crossplane.io"     # All RDS databases

1spec:
2  activate:
3  - buckets.s3.aws.m.crossplane.io        # Exact S3 buckets
4  - "*.ec2.aws.m.crossplane.io"           # All EC2 resources
5  - clusters.eks.aws.m.crossplane.io      # Exact EKS clusters

Legacy and modern resource versions

Crossplane v2 supports two styles of managed resources:

• Modern v2 style (recommended): Use *.m.crossplane.io domains for namespaced managed resources with better isolation and security
• Legacy v1 style: Use *.crossplane.io domains for cluster-scoped managed resources (maintained for backward compatibility)

Activating modern resources

Most examples in this guide use modern v2 style resources:

1spec:
2  activate:
3  - buckets.s3.aws.m.crossplane.io         # Modern v2 S3 bucket
4  - "*.ec2.aws.m.crossplane.io"            # All modern v2 EC2 resources

Activating legacy resources

To activate legacy v1 style resources, use patterns without .m:

1spec:
2  activate:
3  - buckets.s3.aws.crossplane.io           # Legacy v1 S3 bucket
4  - "*.ec2.aws.crossplane.io"              # All legacy v1 EC2 resources

Mixed activation

You can activate both modern and legacy resources in the same MRAP:

1spec:
2  activate:
3  - "*.aws.m.crossplane.io"                # All modern AWS resources
4  - "*.aws.crossplane.io"                  # All legacy AWS resources

Common activation strategies

Activate everything (default behavior)

The Crossplane Helm chart creates a default MRAP that activates all resources:

1apiVersion: apiextensions.crossplane.io/v1alpha1
2kind: ManagedResourceActivationPolicy
3metadata:
4  name: default
5spec:
6  activate:
7  - "*"  # Activate all MRDs

You can customize this during installation:

1# Disable default activations entirely
2helm install crossplane crossplane-stable/crossplane \
3  --set provider.defaultActivations={}
4
5# Or provide custom default activations
6helm install crossplane crossplane-stable/crossplane \
7  --set provider.defaultActivations={\
8    "*.s3.aws.m.crossplane.io","*.ec2.aws.m.crossplane.io"}

Provider-specific activation

Activate all resources from specific providers:

1apiVersion: apiextensions.crossplane.io/v1alpha1
2kind: ManagedResourceActivationPolicy
3metadata:
4  name: aws-provider-resources
5spec:
6  activate:
7  - "*.aws.crossplane.io"     # All AWS resources
8  - "*.aws.m.crossplane.io"   # All AWS managed resources (v2 style)

Service-specific activation

Activate resources for specific cloud services:

 1apiVersion: apiextensions.crossplane.io/v1alpha1
 2kind: ManagedResourceActivationPolicy
 3metadata:
 4  name: storage-and-compute
 5spec:
 6  activate:
 7  - "*.s3.aws.m.crossplane.io"         # AWS S3 resources
 8  - "*.ec2.aws.m.crossplane.io"        # AWS EC2 resources
 9  - "*.storage.gcp.m.crossplane.io"    # GCP Storage resources
10  - "*.compute.gcp.m.crossplane.io"    # GCP Compute resources

Minimal activation

Activate only the resources you know you need:

1apiVersion: apiextensions.crossplane.io/v1alpha1
2kind: ManagedResourceActivationPolicy
3metadata:
4  name: minimal-footprint
5spec:
6  activate:
7  - buckets.s3.aws.m.crossplane.io       # Just S3 buckets
8  - instances.ec2.aws.m.crossplane.io    # Just EC2 instances
9  - databases.rds.aws.m.crossplane.io    # Just RDS databases

Multiple MRAPs

You can have multiple MRAPs in your cluster. Crossplane processes all MRAPs together and activates any MRD that matches at least one pattern.

Team-based activation

Different teams can manage their own activation policies:

 1# Storage team MRAP
 2apiVersion: apiextensions.crossplane.io/v1alpha1
 3kind: ManagedResourceActivationPolicy
 4metadata:
 5  name: storage-team
 6spec:
 7  activate:
 8  - "*.s3.aws.m.crossplane.io"
 9  - "*.storage.gcp.m.crossplane.io"
10---
11# Database team MRAP  
12apiVersion: apiextensions.crossplane.io/v1alpha1
13kind: ManagedResourceActivationPolicy
14metadata:
15  name: database-team
16spec:
17  activate:
18  - "*.rds.aws.m.crossplane.io"
19  - "*.sql.gcp.m.crossplane.io"

Configuration package activation

Configuration packages can include MRAPs to declare their resource dependencies:

 1# In your Configuration package
 2apiVersion: apiextensions.crossplane.io/v1alpha1
 3kind: ManagedResourceActivationPolicy
 4metadata:
 5  name: web-platform-dependencies
 6spec:
 7  activate:
 8  - buckets.s3.aws.m.crossplane.io       # For static assets
 9  - instances.ec2.aws.m.crossplane.io    # For web servers
10  - databases.rds.aws.m.crossplane.io    # For application data
11  - certificates.acm.aws.m.crossplane.io # For HTTPS

Working with MRAPs

Creating MRAPs

Apply an MRAP like any Kubernetes resource:

1kubectl apply -f my-activation-policy.yaml

Viewing MRAPs

List all MRAPs:

1kubectl get managedresourceactivationpolicies

View MRAP details and status:

1kubectl describe mrap aws-core-resources

Checking activation status

MRAPs track which resources they’ve activated:

 1status:
 2  conditions:
 3  - type: Healthy
 4    status: "True"
 5    reason: Running
 6  activated:
 7  - buckets.s3.aws.m.crossplane.io
 8  - instances.ec2.aws.m.crossplane.io  
 9  - instances.rds.aws.m.crossplane.io
10  - securitygroups.ec2.aws.m.crossplane.io
11  - subnets.ec2.aws.m.crossplane.io
12  - vpcs.ec2.aws.m.crossplane.io

MRAP status conditions

Healthy condition

• Healthy: True, Reason: Running: MRAP works
• Healthy: Unknown, Reason: EncounteredErrors: Some MRDs failed to activate

Troubleshooting MRAPs

MRAP exists but resources aren’t activated

Symptoms: MRAP shows activated: [] or missing expected resources

Causes and solutions:

1. Pattern doesn’t match MRD names

   1# List available MRDs
   2kubectl get mrds
   3
   4# Check your pattern matches
   5kubectl get mrds -o name | grep "your-pattern"
   

2. MRDs don’t exist yet

   • Install the required provider first
   • Providers create MRDs when they start

3. Provider doesn’t support activation

   1# Check provider capabilities
   2kubectl get providerrevision <provider-revision-name> \
   3  -o jsonpath='{.status.capabilities}'
   4# Look for "safe-start"
   

MRAP shows activation errors

Symptoms: MRAP has Healthy: Unknown status with errors

Status condition example:

1conditions:
2- type: Healthy
3  status: "Unknown"  
4  reason: EncounteredErrors
5  message: "failed to activate 2 of 5 ManagedResourceDefinitions"

Solution: select MRAP events for specific failure details:

1kubectl describe mrap <name>
2# Look at the Events section for activation errors

Resources activate when you don’t expect them to

Symptoms: more resources are active than expected

Cause: multiple MRAPs with overlapping patterns (this is normal behavior)

Solution: review all MRAP patterns to understand which policies are activating which resources

1# List all MRAP activation patterns
2kubectl get mrap \
3  -o jsonpath='{range .items[*]}{.metadata.name}: {.spec.activate}{"\n"}{end}'
4
5# Check which MRAPs activated each resource
6kubectl get mrap \
7  -o jsonpath='{range .items[*]}{.metadata.name}: {.status.activated}{"\n"}{end}'

Best practices

MRAPs are additive - multiple MRAPs can activate the same resource without conflicts. This enables team-based activation strategies and Configuration package dependencies.

1. Start specific, broaden as needed - Begin with exact resource names, add wildcards only when beneficial for maintainability
2. Plan for provider evolution - Design wildcard patterns that accommodate new resources as providers add them (for example, *.s3.aws.m.crossplane.io works for future S3 resources)
3. Group related resources logically - Create MRAPs that activate resources teams actually use together
4. Include activation dependencies in Configuration packages - Configuration packages should declare what MRDs they need rather than assuming resources are available
5. Use conservative patterns in shared environments - Avoid overly broad wildcards that activate unnecessary resources when multiple teams share providers

Next steps

• Learn about ManagedResourceDefinitions to understand what MRAPs activate
• See the disabling unused managed resources guide for step-by-step implementation
• Check the API reference for complete MRAP schema documentation