Hacker News Reader

Comment by Jonnax | Hacker News Reader

What are people's favoured ways of managing secrets these days?

Does this look appealing?

If you have an enterprise, HashiCorp Vault has the best features and integrations that I know of (everyone should be using short lived credentials, but who actually does if they're not using Vault?). If you can't use that, AWS Secrets Manager for its simpler integration of secret rotation, and if that's too expensive, AWS SSM PS. Google Cloud Secrets Manager would be analogous to AWS Secrets Manager.

The benefit of AWS Secrets Manager has been that it integrates directly with other services. In ECS/Fargate, you can create a task definition and list secrets to be injected at run time. It also has features like secret rotation so you don't have to roll your own (well, you kinda do w/Lambda, but they have samples), and you can use things like IAM to lock down access per-secret or per-IAM-ARN-hierarchy.

Like everything in AWS, it'll cost you more, but it'll also eliminate a lot of engineering time. If you're trying to pinch pennies, use Vault or something hokey like pulling a token from AWS SSM PS or S3 and rely on IAM roles/profiles/etc for access control.

I'm using the SSM Parameter Store [0] a lot, because of its easy integration in applications – many services can directly pull secrets from it and provide them as environment variables. The secrets can be KMS encrypted and cost a fraction of the Secrets Manager, which I think is just the parameter store with secrets being rotated by a Lambda.

[0] https://docs.aws.amazon.com/systems-manager/latest/userguide...

It also has a pretty generous free tier, so if you're not using very ephemeral creds and you don't need auto rotation, it's a fantastic option (disclaimer though I work at SSM and am biased - glad to hear you also like the product :)

Hashicorp vault is basically industry standard I believe. But there are various cloud APIs too, which have varying degrees of integration with kubernetes.

Unfortunately Vault doesn't have a plugin yet for Docker Swarm still :(

But is Swarm a valuable target? My feeling is that Swarm is going to be EOL'ed in not a so distant future.

Swarm is on its way out. Mirantis bought that part of Docker and they said this:

"The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users."

https://www.mirantis.com/blog/mirantis-acquires-docker-enter...

This is sad. Swarm is simple and effective, like Nomad but easier.

But there's no money in enterprise support contracts for things which are simple and effective.

I feel like so much in the cloud space is actually getting worse because of this. Its like all the old server shufflers and netops guys have taken over.

Agreed. I’ve been working a lot with Swarm over the past year and while it’s not perfect, it has been an overall great experience. I really enjoy the simplicity and tight integration with Docker, and I feel that the ecosystem around Swarm was just starting to mature. Hopefully it remains an option for a while.

Also, I haven’t needed to integrate something like Vault because the Swarm secrets feature covers my use case perfectly.

I'm also using the secrets feature but it's very brittle. If your swarm gets destroyed or you want to migrate servers, it's a huge pain to get those secrets back up and running. Unless I'm missing a better way to do this, I'd love to know!

I currently have my secrets stored in an encrypted text file in case I need to bring them back up.

I do something similar, using Ansible Vault (not to be confused with Hashicorp Vault!) to store the encrypted secrets in my ops directory (separate from the application source code). They’re stored as YAML so very easy to upload/regenerate with Ansible.

Since Swarm is Open Source, it is possible the community will maintain it even after Mirantis/Docker have stopped developing it completely.

We have been trying to simplify Vault + Kubernetes integration in our KubeVault project. https://github.com/kubevault . I would love to hear if you have any thoughts.

I wish this wasnt the case. An open core product shouldn't be the industry standard as it's not truly open source (I doubt HashiCorp would allow a PR that brings enterprise functionality to open core) and the open core/give it away for free model stiffes competition (see Vaults pricing for an example, they know they own the market).

How is open core not truly open source? Of course they wouldn't accept a pull request that makes their pay product obsolete. But open source does not dictate that you must accept all pull requests.

There is nothing stopping you from forking the project and adding all the enterprise functionality you want.

https://github.com/hashicorp/vault/blob/master/LICENSE

(shameless plug) For simple secret management use cases here is an alternative, "gitops" friendly, low "config footprint" tool: https://github.com/bitnami-labs/sealed-secrets

Vault is also operationally complex and does a lot more than you need most of the time.

Azure Keyvault: https://docs.microsoft.com/en-us/azure/key-vault/key-vault-o...

(shameless plug as well) Try out CyberArk DAP (formerly Conjur): https://hub.docker.com/r/cyberark/conjur. OSS, powerful RBAC, has k8s-native workload ident auth, works on OCP and w/ PCF, lots of tooling integrations (https://github.com/cyberark/summon, https://github.com/cyberark/secretless-broker, etc), and there's a relatively straightforward path up to "enterprise"-y stuff if you think you want the bells and whistles (replication, auto-deployable followers, multi-zone failover, etc).

As others have mentioned, also using SSM Parameter Store (if you're in AWS) + KMS. Running most of our micro services using ECS (Fargate) which can populate environment variables directly from secrets in SSM Parameter Store.

AWS Secrets Manager is fine if you're in that cloud. We inject all our secrets into the API containers' environments when they're deployed. For some things that have refresh tokens and access tokens with shorter lifetimes, we use the Secrets Manager API to fetch them when necessary at runtime.

What do you use for per customer keys?

Salt+gpg works, although there are a lot of assumptions baked into that.

Reply on news.ycombinator.com