Open krish7919 opened 6 years ago
It is strange to me that this has gotten no traction. After installing vault, vault operator init is the first command you have to run. The whole idea of terraform is to automate deployment of infrastructure. Requiring a manual step between creating your infrastructure & deploying vault, then manually initting vault then running another terraform run to configure vault is the antithesis of what terraform is supposed to do. Apparently I'm the only one who feels this way - Did I miss something?
Exactly. And I run Vault on k8s, and I had started to write a Vault Controller to initialise Vault (https://github.com/krish7919/vault-controller), but have a long way to go there.
This is a core gap in the deployment and usage of Vault.
EDIT: We moved from managing Vault using Terraform a long time ago, as we deployed Vault using Helm on K8s, then do manual stuff, then switch to Terraform to configure, then start using it. It was a pita.
Judging by the fact there's not been an official reply from hashicorp
we may need to implement this functionality ourselves. There's already an example to follow at least here. The only bit missing is the unseal
functionality.
Just wanted to provide an update that we are currently discussing this feature request internally. When we have some news we will post an update here.
Thank you for the update, I'm happy to help if I can.
The code changes for this are pretty trivial. I have a working copy here: https://github.com/albeego/terraform-provider-vault/tree/main
the main issues on this are documentation, consumer education and risks. I asked the questions here on the forums: https://discuss.hashicorp.com/t/vault-consul-bootstrap-initialisation-and-unsealing/36114/4 the responder was quite dismissive of the idea and implied it was bad practice.
I've not really worked on any tests or documentation for the changes. I got the distinct impression that it's not wanted. If that's not the case and there is any interest I'd happily work the PR up into something more mergable.
For reference the way we intend to use it is to deliver the unseal keys and individual user tokens for each of our engineers and persons of responsibility to personal vaults in OnePassword then remove any references to those secrets from the state. That way, we can seal and unseal vault ourselves when it's up and running in response to security incidents and we can do blue green deployments for any upgrades
Any movement on this?
The code changes for this are pretty trivial. I have a working copy here: https://github.com/albeego/terraform-provider-vault/tree/main
the main issues on this are documentation, consumer education and risks. I asked the questions here on the forums: https://discuss.hashicorp.com/t/vault-consul-bootstrap-initialisation-and-unsealing/36114/4 the responder was quite dismissive of the idea and implied it was bad practice.
I've not really worked on any tests or documentation for the changes. I got the distinct impression that it's not wanted. If that's not the case and there is any interest I'd happily work the PR up into something more mergable.
For reference the way we intend to use it is to deliver the unseal keys and individual user tokens for each of our engineers and persons of responsibility to personal vaults in OnePassword then remove any references to those secrets from the state. That way, we can seal and unseal vault ourselves when it's up and running in response to security incidents and we can do blue green deployments for any upgrades
Hi there! I apologize for your poor experience on Discuss. The user who replied does not represent HashiCorp, and has since been suspended for other reasons.
As for this request, I'll check with our engineering teams. I can't make any guarantees as to outcome, but I'll bubble it up for visibility with them. Thanks for your patience!
We moved away from Vault to completely depend on AWS Secrets Manager, AWS IAM roles/policies, AWS RDS IAM Auth, etc. This should come as no surprise and was a long time coming, as now many, many teams would face this init issue and the most common thing for them would be to manage database and AWS credentials, which are the services provided by IAM.
As our infrastructure has evolved, I do not see the need for this issue almost 4.5 years after this was opened, and can be closed, unless there are other reasons that the Vault team is looking to provide this feature now.
Thanks for the update @hsimon-hashicorp . For me, I've actually created a job that automatically runs an init against the Vault API and then does some unseal stuff.
However, for the init
, if it doesn't pose any serious security issues, I wonder if it would be possible to somewhat integrate it in some form with the auto-unseal features of AWS KMS, Azure KeyVault etc? I know it handles the unsealing, but wondering how much more complex it would be if it was to also handle the init
? If this wasn't possible, maybe just having an init
resource available to do this?
I spoke with our engineering teams, and this feature request is planned for evaluation and possible inclusion in a release within the first half of the coming year. I'm sorry I can't be more specific - I don't want to make any promises that I can't keep. But please know that we hear you and we're always trying to make the product better and our practitioners' lives easier. Thanks again for your patience!
I spoke with our engineering teams, and this feature request is planned for evaluation and possible inclusion in a release within the first half of the coming year. I'm sorry I can't be more specific - I don't want to make any promises that I can't keep. But please know that we hear you and we're always trying to make the product better and our practitioners' lives easier. Thanks again for your patience!
Thanks for the update ☺️ and the kind words too. All appreciated and so are your products a d services 🥰
Hi there! @hsimon-hashicorp Did you hear any news from the engineering team? Does this feature already present on the current roadmap?
Hi, I'm facing the same issue and would like to know if there is any update. It would be a nice resource to have. And will make the setup easier and faster. Thanks
I agree that this feature is needed. Any timeline on this?
Hello everyone, I was wondering if there have been any recent updates or developments regarding this discussion. Could someone please provide an update if there is any? Thank you
Hello, we do not have any timeline set for this yet.
The Vault ecosystem team that manages the TFVP is trying to improve upon the long term sustainability of this project and scale this project's development by collaborating with more teams and contributors. This collaborative effort has growing pains and is slow, so we apologize and appreciate the patience.
This is more of a question rather than an issue.
What are the ways to initialize vault? Is there only a manual way to initialize vault?
I understand that Vault must be initialized by a trusted individual/s and that the unseal keys should be maintained by different folks to avoid compromising the security of the credentials infrastructure.
However, our infrastructure is managed by trusted team/individuals who control the overall cluster and it would seem odd to involve a manual step in the way; our terraform.tfstate have a lot of secrets/information which need to be secure, and not just the vault keys. Also, I would like to have a pure
infrastructure as code
environment to quickly recover or set up a new cluster.Does it make sense to add a
vault_operator_init
resource and thevault_operator_unseal
resource to the terraform provider to ease deployments and management of vault?