You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great to see the option specially when selecting cloud providers like AWS to be able to select which secret manager the user would like to use in their cluster.
For example, I have been using AWS Secret Manager with our EKS cluster for application config and it will be really great select this during the installation time.
I know, as of now I can do this by updating the GitOps repo, but as a product I would be good to see this feature in the installation step
Why is it needed?
This will give users more flexibility to move to this product.
Is this missing feature preventing you from using kubefirst?
Yes
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
As you wrote, nothing prevents you to manage your secrets with another provider once the cluster is created, but kubefirst is right now tightly coupled with HashiCorp Vault to manage not only secrets within services and applications, and also as an OIDC provider, which give you SSO abilities within the platform. Only the engineering team will be able to give a better feasibility estimate for that, but I doubt it's something trivial. For now it's not a priority, even if we understand the desire to use the tool you already know, but maybe in the future we will have tooling selection right at the creation step.
In the meantime, others can vote on this feature request.
What is your feature idea?
Hi,
It would be great to see the option specially when selecting cloud providers like AWS to be able to select which secret manager the user would like to use in their cluster.
For example, I have been using AWS Secret Manager with our EKS cluster for application config and it will be really great select this during the installation time.
I know, as of now I can do this by updating the GitOps repo, but as a product I would be good to see this feature in the installation step
Why is it needed?
This will give users more flexibility to move to this product.
Is this missing feature preventing you from using kubefirst?
Code of Conduct
The text was updated successfully, but these errors were encountered: