Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI Flag for KMS Encryption #1906

Closed
trevorrobertsjr opened this issue Mar 8, 2020 · 1 comment
Closed

CLI Flag for KMS Encryption #1906

trevorrobertsjr opened this issue Mar 8, 2020 · 1 comment
Labels
kind/feature New feature or request

Comments

@trevorrobertsjr
Copy link

Before creating a feature request, please search existing feature requests to see if you find a similar one. If there is a similar feature request please up-vote it and/or add your comments to it instead

Why do you want this feature?
It would be helpful to users if the CLI has feature parity compared to using a YAML file when enabling KMS encryption during cluster creation.
I checked the create_cluster.go, the cluster.go, and the cmdutils.go files, but neither have a reference to this functionality.

What feature/behavior/change do you want?
Ideally, the CLI flag (ex: --secretsencryption) would have two behaviors:

  1. if no KMS ARN is specified, eksctl creates a KMS key and uses it as the input parameter to the EKS cluster creation.
    eksctl create cluster --name=mycluster --nodes=3 --managed --secretsencryption

  2. If the user specifies the KMS ARN, use that KMS key as the input parameter to the EKS cluster creation.
    eksctl create cluster --name=mycluster --nodes=3 --managed --secretsencryption=myARN

@trevorrobertsjr trevorrobertsjr added the kind/feature New feature or request label Mar 8, 2020
@martina-if
Copy link
Contributor

Hi @trevorrobertsjr, thank you for reporting this use case. When designing eksctl we follow the convention that advanced features exist only in the config file so there won't be feature parity between CLI flags and the config file by design. The main reason for this is that we aim to keep a clean and simple UX and adding all the flags would be overwhelming.

In addition, we want to promote the use of config files as best practices for managing clusters so I would like to encourage you to try it out :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants