Eksctl: Option to pass stack names to the CLI as flags/parameters

[olipachi]

Why do you want this feature?
My company does some naming-based permission enforcement (i.e. can't create stacks without a label appended to the front). The 'eksctl-' is what breaks my particular use case.

What feature/behavior/change do you want?
I would like the ability to pass the stack name, using something like --stack-name, OR the ability to disable the prepending of 'eksctl-' to stack names, so that my prefix being used for permission enforcement doesn't get lost.

Since I know that eksctl creates 2 stacks, the cluster and nodegroup stack, maybe the option of passing --cluster-name and --nodegroup-name, or something along those lines, would be better. Again, in my scenario, the 'eksctl-' that gets added to the front is causing my issue. However, I think giving the user control over the stack names overall is probably a better solution than just omitting the 'eksctl-' prefix.

[errordeveloper]

This is potentially doable, but probably only via config files.

[errordeveloper]

@olipachi please let us know if it's a blocking issue for you, or you found a way to get around it?

[jwalters-gpsw]

Any feedback on this? I'm having the same "issue".

[jwalters-gpsw]

Any feedback on this? I'm having the same "issue".

I'm thinking the answer is no: https://github.com/weaveworks/eksctl/blob/ca9f7332a759a328e44d64a7d47f6dfddb65f17a/pkg/cfn/manager/cluster.go#L24

[errordeveloper]

At this stage we only had one person requesting this, now we have two, thanks for letting us know! We will consider this feature request soon. It would help to know how does the issue affect you?

[errordeveloper]

Per #825, we will need to support empty prefix also. I guess it would be reasonable to explore the idea of having no prefix, leaving us with two modes - eksctl- prefix or empty prefix, and it maybe possible to support both without a parameter. If one needs a custom prefix, they will need to include it in cluster name.

[maynardflies]

This is a blocker for us as well, because our company enforces a naming scheme which controls the prefixes of all resources. Any word on this?

[xDeany]

I have also found that the current naming convention eksctl uses does not persist through to the IAM policies it creates. We added an exception in our company for 'eksctl-XXXX' but the IAM policies it creates are all truncated weirdly 'eksct-Poli-8RXD6...' and break this rule. Unsure if this is a seperate bug or something that could be fixed by this current request

[jarawhirl]

+1 on the need to have the enhancement in our company.

[pborgen]

Would be nice to this flexibility

[MattyKuzyk]

This makes eksctl unusable at my company for the same reason. We enforce prefixes org wide.

[olipachi]

Hey guys, circling back on this. Glad I'm not the only one who wants this feature! :)

As before, I still really want to leverage eksctl at my company but unfortunately we do all sorts of things based on resource prefixes so it is still unusable to us. Very excited to see if this feature request will get any traction.

[dectl]

Need this also. Company enforces prefixes.

[uycarumba]

We in the company also need this functionality, due to control and government policies.
:)

[jalaziz]

We could also use this feature!

However, until it lands, we've decided to pre-create all the cluster resources that can't be easily renamed or replaced once the cluster is created.

The three resources we had to provide were:

• sharedNodeSecurityGroup (attached to nodes)
• securityGroup (the control plane security group, not entirely sure this is still need with eks 1.14+)
• serviceRoleARN (the cluster role)

That being said, the security group that EKS creates automatically is not configurable and has its own naming convention which violates our naming rules. Unfortunately, the best we can do do for that security group is tag it appropriately.

[chrisjohnson00]

Not a blocker for using this, but would be nice. The eksctl stacks don't follow the standard convention we have, so the generated ones are "out of place" but not rejected.