Override CARM Account ID

[starlightromero]

Is your feature request related to a problem?

When trying to manage an application and it's dependencies both inside and outside of EKS, it may be necessary to create AWS resources in both the EKS cluster's AWS account (222222222222) and a separate application-focused AWS account (111111111111).

For example when having an application with the following resources:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- iam-policy.yaml
- iam-role.yaml
- secretsmanager-secret.yaml
- secret-store.yaml
- external-secret.yaml
- hpa.yaml
- pdb.yaml
- service.yaml
- deployment.yaml
- ingress.yaml
- certificate.yaml
- network-policy-default-deny-all.yaml
- network-policy-allow-ingress.yaml
- network-policy-allow-egress.yaml
- ec2-security-group.yaml

Deployed in a namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: dev-app
  labels:
    app.kubernetes.io/name: app
    app.kubernetes.io/environment: dev
    app.kubernetes.io/owner: owner-a
  annotations:
    services.k8s.aws/team-id: team-a

With the following team map:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-role-team-map
  namespace: ack-system
data:
  acm.team-a arn:aws:iam::111111111111:role/med-prod-ack-acm-controller
  acmpca.team-a: arn:aws:iam::111111111111:role/med-prod-ack-acmpca-controller
  ec2.team-a: arn:aws:iam::111111111111:role/med-prod-ack-ec2-controller
  ecr.team-a: arn:aws:iam::111111111111:role/med-prod-ack-ecr-controller
  eks.team-a: arn:aws:iam::111111111111:role/med-prod-ack-eks-controller
  iam.team-a: arn:aws:iam::111111111111:role/med-prod-ack-iam-controller
  kms.team-a: arn:aws:iam::111111111111:role/med-prod-ack-kms-controller
  rds.team-a: arn:aws:iam::111111111111:role/med-prod-ack-rds-controller
  route53.team-a: arn:aws:iam::111111111111:role/med-prod-ack-route53-controller
  s3.team-a: arn:aws:iam::111111111111:role/med-prod-ack-s3-controller
  secretsmanager.team-a: arn:aws:iam::111111111111:role/med-prod-ack-secretsmanager-controller
  sqs.team-a: arn:aws:iam::111111111111:role/med-prod-ack-sqs-controller

A resource such as a SecretsManager Secret should be in AWS account 111111111111 where developers have permission to access and modify secrets. But a resource such as an EC2 Security Group used for Pod Security Groups should be in the EKS cluster's account 222222222222

Describe the solution you'd like

It would be ideal if there was a way to override the CARM and use the default roles/policies in the default account.

apiVersion: ec2.services.k8s.aws/v1alpha1
kind: SecurityGroup
metadata:
  name: dev-app
  namespace: dev-app
  annotations:
    services.k8s.aws/override: 222222222222
spec:
  ...

Please feel free to choose a better annotation setup.

Describe alternatives you've considered

The current workaround to this is to provision the EC2 Security Group in a different namespace, then the SecurityGroupPolicy in the application namespace.

[github-actions]

Hello @starlightromero 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[artyom-p]

Similar situation, I'm using EKS and IAM controllers to provision IAM roles and PodIdentityAssociations, PIA should be in account(111111111111) and role in account(222222222222), but because the annotation can be set on ns only, setting it on CR's doesn't work for me, resources should be provisioned in a different ns (as a workaround). It would be super useful to make annotations work on actual CRs, overriding the namespace rules if they exist.