Managed Resource Activation Policies

{{<hint "important">}} Managed resource activation policies work with [managed resource definitions]({{<ref "managed-resource-definitions">}}), which Crossplane v2.0+ enables by default. To disable this behavior, set --enable-custom-to-managed-resource-conversion=false when installing Crossplane. {{</hint>}}

A ManagedResourceActivationPolicy (MRAP) controls which [ManagedResourceDefinitions]({{<ref "managed-resource-definitions">}}) 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

apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: aws-core-resources
spec:
  activate:
  - buckets.s3.aws.m.crossplane.io      # Modern v2 style S3 buckets
  - instances.rds.aws.m.crossplane.io   # Modern v2 style RDS instances
  - "*.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:

spec:
  activate:
  - buckets.s3.aws.m.crossplane.io
  - databases.rds.aws.m.crossplane.io
  - clusters.eks.aws.m.crossplane.io

{{<hint "important">}} Use the plural name when using a complete MRD name, aligning with how Kubernetes expresses the complete names of CRDs.

For example, use buckets, as opposed to bucket, in buckets.s3.aws.m.crossplane.io. {{</hint>}}

Wildcard patterns

Use * wildcards to match multiple resources:

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

{{<hint "important">}} MRAPs use prefix-only wildcards, not full regular expressions. Only * at the beginning of a pattern works (for example, *.s3.aws.m.crossplane.io). Patterns like s3.*.aws.m.crossplane.io or *.s3.* aren't valid. {{</hint>}}

{{<hint "tip">}} You can mix exact names and wildcards for flexible activation:

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

{{</hint>}}

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:

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

Activating legacy resources

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

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

Mixed activation

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

spec:
  activate:
  - "*.aws.m.crossplane.io"                # All modern AWS resources
  - "*.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:

apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: default
spec:
  activate:
  - "*"  # Activate all MRDs

You can customize this during installation:

# Disable default activations entirely
helm install crossplane crossplane-stable/crossplane \
  --set provider.defaultActivations={}

# Or provide custom default activations
helm install crossplane crossplane-stable/crossplane \
  --set provider.defaultActivations={\
    "*.s3.aws.m.crossplane.io","*.ec2.aws.m.crossplane.io"}

Provider-specific activation

Activate all resources from specific providers:

apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: aws-provider-resources
spec:
  activate:
  - "*.aws.crossplane.io"     # All AWS resources
  - "*.aws.m.crossplane.io"   # All AWS managed resources (v2 style)

Service-specific activation

Activate resources for specific cloud services:

apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: storage-and-compute
spec:
  activate:
  - "*.s3.aws.m.crossplane.io"         # AWS S3 resources
  - "*.ec2.aws.m.crossplane.io"        # AWS EC2 resources
  - "*.storage.gcp.m.crossplane.io"    # GCP Storage resources
  - "*.compute.gcp.m.crossplane.io"    # GCP Compute resources

Minimal activation

Activate only the resources you know you need:

apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: minimal-footprint
spec:
  activate:
  - buckets.s3.aws.m.crossplane.io       # Just S3 buckets
  - instances.ec2.aws.m.crossplane.io    # Just EC2 instances
  - 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:

# Storage team MRAP
apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: storage-team
spec:
  activate:
  - "*.s3.aws.m.crossplane.io"
  - "*.storage.gcp.m.crossplane.io"
---
# Database team MRAP
apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: database-team
spec:
  activate:
  - "*.rds.aws.m.crossplane.io"
  - "*.sql.gcp.m.crossplane.io"

Configuration package activation

Configuration packages can include MRAPs to declare their resource dependencies:

# In your Configuration package
apiVersion: apiextensions.crossplane.io/v1alpha1
kind: ManagedResourceActivationPolicy
metadata:
  name: web-platform-dependencies
spec:
  activate:
  - buckets.s3.aws.m.crossplane.io       # For static assets
  - instances.ec2.aws.m.crossplane.io    # For web servers
  - databases.rds.aws.m.crossplane.io    # For application data
  - certificates.acm.aws.m.crossplane.io # For HTTPS

Working with MRAPs

Creating MRAPs

Apply an MRAP like any Kubernetes resource:

kubectl apply -f my-activation-policy.yaml

Viewing MRAPs

List all MRAPs:

kubectl get managedresourceactivationpolicies

View MRAP details and status:

kubectl describe mrap aws-core-resources

Checking activation status

MRAPs track which resources they've activated:

status:
  conditions:
  - type: Healthy
    status: "True"
    reason: Running
  activated:
  - buckets.s3.aws.m.crossplane.io
  - instances.ec2.aws.m.crossplane.io
  - instances.rds.aws.m.crossplane.io
  - securitygroups.ec2.aws.m.crossplane.io
  - subnets.ec2.aws.m.crossplane.io
  - 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

   shellCopy

   # List available MRDs
   kubectl get mrds
   
   # Check your pattern matches
   kubectl 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

   shellCopy

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

MRAP shows activation errors

Symptoms: MRAP has Healthy: Unknown status with errors

Status condition example:

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

Solution: select MRAP events for specific failure details:

kubectl describe mrap <name>
# 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

# List all MRAP activation patterns
kubectl get mrap \
  -o jsonpath='{range .items[*]}{.metadata.name}: {.spec.activate}{"\n"}{end}'

# Check which MRAPs activated each resource
kubectl get mrap \
  -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 (using the plural name for each resource), 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]({{<ref "managed-resource-definitions">}}) to understand what MRAPs activate
• See the [disabling unused managed resources guide]({{<ref "../guides/disabling-unused-managed-resources">}}) for step-by-step implementation
• Check the [API reference]({{<ref "../api">}}) for complete MRAP schema documentation