Q: Your company's Crossplane AWS provider uses static IAM user access keys stored in a Kubernetes Secret. A security audit mandates immediate revocation of all static keys and non-disruptive rotation every 24 hours. How do you migrate Crossplane to IRSA without disrupting ongoing infrastructure reconciliation?

Create an AWS IAM role trusting the EKS cluster's OIDC identity provider, scoped specifically to the Crossplane provider's ServiceAccount.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E080826BA80423"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E080826BA80423:sub": "system:serviceaccount:crossplane-system:provider-aws-upjet"
        }
      }
    }
  ]
}

Update the Crossplane `ProviderConfig` from `source: Secret` to `source: InjectedIdentity` (IRSA).

apiVersion: aws.upjet.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: InjectedIdentity

Annotate the provider ServiceAccount with `eks.amazonaws.com/role-arn`. The AWS SDK inside the provider pod automatically reads the mounted web identity token, rotating credentials every hour with zero manual intervention.

kubectl annotate serviceaccount -n crossplane-system provider-aws-upjet \
  eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/crossplane-provider-role \
  --overwrite

After verifying that `kubectl get managed` resources remain in `Ready=True`, safely delete the static IAM access keys in AWS Console/CLI.