Split CARMv2 functionality into Team Level Role and Service Level Role

[TiberiuGC]

Issue #, if available:

Description of changes:

This PR aims to resolve a concern where a user migrating from CARMv1 to v2 (i.e. to teamIDs and service level isolation support) might end up with their resources re-created into incorrect accounts just by enabling the feature flag, due to lack of v2 configuration.

The PR splits CARMv2 feature into 2 different features, each behind its own feature flag:

1. team level role - TeamLevelCARM , the mappings are being stored in a new configmap ack-role-team-map
2. service level role - ServiceLevelCARM , the mappings can be stored in both the existing configmap ack-role-account-map and the new configmap ack-role-team-map

When both feature flags are ENABLED, the configmap setup may look like below (this is currently all squeezed into the CARMv2 map i.e. ack-carm-map):

ack-role-team-map 👇

data:
  team-a: "arn:aws:iam::111111111111:role/team-a-global-role"
  s3.team-a: "arn:aws:iam::111111111111:role/team-a-s3-role"
  dynamodb.team-a: "arn:aws:iam::111111111111:role/team-a-dynamodb-role"

ack-role-account-map 👇

data:
  111111111111: arn:aws:iam::111111111111:role/global-role
  s3.111111111111: arn:aws:iam::111111111111:role/s3-role
  dynamodb.111111111111: arn:aws:iam::111111111111:role/dynamodb-role 

When both feature flags are DISABLED, or neither teamID annotation or service level roles are setup, runtime continues to use the existing CARMv1 setup:

ack-role-account-map 👇

data:
  111111111111: arn:aws:iam::111111111111:role/global-role

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ack-prow]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[TiberiuGC]

/test all

[a-hilaly]

This is great work! Thanks Tibi!

[a-hilaly]

Can we add a comment stating that we're looking i the classic CARM?

[TiberiuGC]

The comment is stating we're looking in Accounts configmap. Which is the default one. I refrained from using CARMv1 and v2 terminology as with this new approach.

[a-hilaly]

/retest

[a-hilaly]

/retest

[TiberiuGC]

/retest

[a-hilaly]

This looks stable to me. Any other updates you want to make to the code/PR description? cc @TiberiuGC

[TiberiuGC]

This looks stable to me. Any other updates you want to make to the code/PR description? cc @TiberiuGC

I could rename the flags as per your suggestion, just to be more descriptive? TeamLevelCARM/ServiceLevelCARM e.g.

--feature-gates TeamLevelCARM=true

[TiberiuGC]

This looks stable to me. Any other updates you want to make to the code/PR description? cc @TiberiuGC

I could rename the flags using your suggestion, just to be more descriptive? TeamLevelCARM/ServiceLevelCARM e.g.

--feature-gates TeamLevelCARM=true

Done c2213da

[a-hilaly]

/test all

[a-hilaly]

/test all

[a-hilaly]

Great stuff, thanks a lot @TiberiuGC !
/lgtm

[a-hilaly]

/retest

[a-hilaly]

/test all

[a-hilaly]

/retest

[a-hilaly]

/lgtm

[ack-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: a-hilaly, TiberiuGC

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [a-hilaly]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment