Create multiple namespaces within single ApplicationTeam

[delta549]

Describe the feature

I can't seem to find a graceful way to specify multiple namespace creations and attach this to a single team.
This proposal suggests a change to the namespace TeamProps and underlying functionality to create a namespace based on a provided string[] of namespace names. These will be created following the usual process, but can be accessed by the overall team.

export class TeamAwesome extends ApplicationTeam {
    constructor(app: App) {
        super({
            name: "team-awesome",
            users: [
                new ArnPrincipal(`arn:aws:iam::${YOUR_IAM_ACCOUNT}:user/user1`),  
                new ArnPrincipal(`arn:aws:iam::${YOUR_IAM_ACCOUNT}:user/user2`)
            ],
            namespace: "my-namespace" // <--- Single namespace associated with team
        });
    }
}

Use Case

The impact:

This would be incredibly useful for larger organisations which may have teams that wish to use multiple namespaces associated to a single team. Even the ability to specify a dev namespace per team member for small testable depoyments.

The outcome:

The optional namespaces array (when added) will create an eks-blueprints compliant namespace for every array entry. These namespaces will be associated to the team and attach to all users.

Proposed Solution

Example new ApplicationTeam:

export class TeamAwesome extends ApplicationTeam {
    constructor(app: App) {
        super({
            name: "team-awesome",
            users: [
                new ArnPrincipal(`arn:aws:iam::${YOUR_IAM_ACCOUNT}:user/user1`),  
                new ArnPrincipal(`arn:aws:iam::${YOUR_IAM_ACCOUNT}:user/user2`)
            ],
            namespaces: ["namespace-one", "namespace-two", "namespace-three"] // <--- Instead of specifying one namespace?
        });
    }
}

Other Information

No response

Acknowledgements

• I may be able to implement this feature request

CDK version used

2.174.0

EKS Blueprints Version

1.16.3

Node.js Version

20.16.0

Environment details (OS name and version, etc.)

Ubuntu 24.04.1

[shapirov103]

@delta549 thank you for your feedback.
Let me share someinfo to make sure we consider all the implications. In addition to the cluster access, the namespace that we create for the team is used for 1/ service accounts to access external resources with the specified policies and 2/ secrets (e.g. with CSI secret store). These are namespace resources.

The question to answer here is whether we need to duplicate these resources across the namespaces as well. It is one option, however, I can see how these service accounts/policies and secrets can be different per namespace. If we go down that path we will have to allow passing those per namespace as well.

The team itself is a set of IAM users or a particular role userRoleArn that is shared by a set of users. In the current setup you can create a team of users as an array of users or define a userRole for each team and create multiple team objects with different namespaces passing the same set of principals to each but retaining a way to have different service accounts and secrets in each.

For a larger enterprise, it may be reasonable to create a subclass of a team, like DevTeam that captures access policies and guardrails and then instantiate it with some naming convention as many times as you need, e.g. "team-A-prod", "team-A-sandbox", "team-A-experiment1".

Another approach is to introduce a clear separation of concerns between team and its workloads. In this case, the team construct can have an array of workloads under it containing namespace, service account, secrets, etc. This becomes and new type of a team, as we will need to preserve compatibility.