1

We have a bunch of Windows server applications that currently handle secrets as follows; our apps are in C#.

  • We store them in settings files in code
  • We store them encrypted, using a certificate
  • The servers have this certificate with the private key, so they can decrypt the secret

We're looking at implementing Hashicorp Vault. It seems easy enough to simply replace the encrypt-store-decrypt with storing the secret in Vault in the KV engine, and just grabbing it in our apps - that takes that certificate out of the picture entirely. Since we're on-prem, I'll need to figure out our auth method.

We have different apps running on different machines, and it's somewhat dynamic (not as much as an autoscaling scenario, but not permanent - so we can't just assign servers to roles one time and depend on Kerberos auth).

I'm unsure how to make AppRole work in our scenario. We don't have one of the example "trusted platforms" or "trusted entities", there's no Nomad, Chef, Terraform, etc. We have Windows machines, in a domain, and we have a homegrown orchestrator that could be queried to say "This machine name runs these apps", so maybe there's something that can be done there?

Am I in "write your own auth plugin" territory, to speak to our homegrown orchestrator?

Edit - someone on Reddit suggested that this is a simple solution if our apps are all 1-to-1 with the Windows domain account they run under, because then we can just use kerb authentication. That's not currently the way we're architected, but we've got to solve this somehow, and that might do it nicely.

2nd edit - replaced "services" with "apps", since most of our services aren't actually running as Windows services, just processes. The launcher is a Windows service but the individual processes it launches are not.

mfinni
  • 65
  • 1
  • 17

2 Answers2

0

How about Group Managed Service Accounts? https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

Essentially you created one "trusted platform" (to your key vault service). Your service can still has its own identity but delegation to the gMSA when you want to retrieve the secrets.

LarryX
  • 591
  • 2
  • 7
  • Isn't that what I'm suggesting in my edit? We're currently running most of our processes as a single account, but we can probably get them running under individual GMSAs. – mfinni Jul 19 '21 at 05:34
  • Not exactly gMSA is a single account that can be assigned to a group of machines. It is more of machine identity than service identity.. unless all the services are identical or doesn't need any identities other than accessing KV, you don't have to assign gMSA to service. You uses https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/configure-kerberos-delegation-group-managed-service-accounts – LarryX Jul 19 '21 at 10:18
  • I understand how to use GMSA, we already do. Please further explain how we get to the goal of "this app can retrieve it's own secrets, and not the secrets of any other app" because I'm not seeing it in your explanation. – mfinni Jul 19 '21 at 16:27
  • ok if you need both authN & authZ, yes 1:1 service accounts are required. – LarryX Jul 19 '21 at 23:32
  • So, you're just confirming what I wrote in my edit? – mfinni Jul 19 '21 at 23:38
  • I read the AppRole in Hashicorp doc, The app role id seems just a guid that you can set to environment variable etc. If you uses pipeline to deploy all your app, it is pretty simple to inject that piece of info into your app. You can still use a single service account to do response wrapping API to retrieve the secret for the app role id – LarryX Jul 20 '21 at 11:38
  • That's not the scenario we have, we don't have a pipeline that does that. Thus my question. Also, it seems like you don't have much first-hand experience with Vault? I'm not asking here for someone to read the docs to me. – mfinni Jul 20 '21 at 14:59
  • You can do it manually during the the manual deployment, just that it is going to be more error prone. – LarryX Jul 21 '21 at 10:47
  • No, we have 3000 machines that can run a variety of 22 different processes. We're not doing anything manually. – mfinni Jul 21 '21 at 15:22
  • how do you get the processes up there, make updates etc.(application deployment)? – LarryX Jul 21 '21 at 15:33
  • We have our homegrown orchestrator that pushes out new code on deployments, which happen a few times a month. There are time when we make changes to which machines run which processes, which is somewhat independent of actual centralized deployment. That's why I asked "Am I in "write your own auth plugin" territory, to speak to our homegrown orchestrator?" – mfinni Jul 21 '21 at 17:51
  • that is ci/cd pipeline is for. I hope your homegrown orchestrator (that could be queried to say "This machine name runs these apps") is not trying to replace the standard pipeline tools – LarryX Jul 21 '21 at 18:53
  • We don't have any of those tools- if we did, we'd use them. Our tech is several years old, homegrown, on-prem, and Windows-native. If I could use the existing Vault out-of-the-box integrations, I would, and wouldn't be asking this question. – mfinni Jul 21 '21 at 18:57
  • ok makes sense now. you will need to figure out how to push the app role id to the apps – LarryX Jul 21 '21 at 19:36
  • So we spent a lot of time reiterating my questions. Thanks. – mfinni Jul 21 '21 at 21:23
  • If I knew you guys has skill to home grow tools used in such large scale workload, I won't dare to try to help:-) – LarryX Jul 21 '21 at 22:17
0

For future visibility, here's what we landed on:

TLS certificate authentication. Using Vault, we issue a handful of certs, each will correspond to a security policy/profile, so that any machine that holds that certificate will be able to authenticate and retrieve the secrets they should have access to.

  1. Kerberos ended up being a dead-end for two reasons. The vault.exe agent (which is part of this use case) can't use the native Windows Kerberos SSPI, so we'd have to manage and distribute keytab files. Also, if we used machine authentication, it would blow up our client count (we're using the cloud-hosted HCP Vault, where pricing is partially based on client count).
  2. Custom plugins can't be loaded into the HCP, of course
  3. Azure won't work, it requires Managed Identities which you can't assign to on-prem machines. Otherwise this might have been a great fit
mfinni
  • 65
  • 1
  • 17