5 ms·

I agree with this. But I want to ask a similar question as OP but for services. How do you handle service account credentials in a good way? Typically multiple

I agree with this. But I want to ask a similar question as OP but for services. How do you handle service account credentials in a good way? Typically multiple engineers need to be able to test out a given service account. So a number of users need to have access to the credentials of that service account. And you need a good way to enroll a new service to service connection, i.e give a service account access to another service. I haven't seen this done in a way that didn't feel overly complex, prone to error and oversharing of secrets.

karmakaze 2y ago
> the credentials of that service account Why do these accounts only have a single user/password? In any case, my answer would again be automation. Script the test, have the authorized process test out the service account on behalf of any employee who can create and run those tests.
- crazygringo 2y ago
  Because that's just how some products are set up. Not every external service account provides separate passwords for different employees, there's just a single corporate account that some certain number of people need to have access to. And automation isn't an answer to that. The question is how to share the password in the first place, not to automate what is done with it.
  - Maxion 2y ago
    I've bumped into this with various API integrations to e.g. warehousing systems, ERPs, hosting providers and what not. The advice in this thread works great until you are on a project to integrate X API into Y project, and you need the admin dashboard. Now you have three developers who all need to share one account.
ethbr1 2y ago
You need to be able to automate 3 things: 1. Account pass retrieval 2. Account pass rotation 3. Account pass ref update (1) is how a user gets the pass when needed (normal process or break glass debug). (2) is how the pass rotates to an unknown value, automatically, after the user is done with it. (3) is how the new value gets updated in references, without the user knowing the new value. At the root of any solution are answers to those 3 needs.
zie 2y ago
The best way to handle service accounts is nobody knows the password. When X needs to troubleshoot, they change the password, do what needs to be done, then change it again afterwards, to some unknown value. It's a lot easier if you automate the password delivery to the service account. 1Password can do this with their CLI offering and Vault/OpenBAO can also do this. There are other password managers that can do similar things as well. With Vault/OpenBAO, for many services, it can handle password rotation and can even generate accounts(with appropriate permissions) for you, so you need access to Y service, Vault will create a temporary account. When the token expires, it will delete the account automatically. If you can't get there yet, then you limit the damage by limiting the shared password to a small set of people, use a password manager and as soon as any one of them leave the group, rotate the password.
- jareklupinski 2y ago
  > The best way to handle service accounts is nobody knows the password. When X needs to troubleshoot, they change the password, do what needs to be done, then change it again afterwards, to some unknown value. one way i've seen this is on a 'lease' system: your user requests access to use the account, the system logs your request and generates a random password for you, you log in and use the account for the duration of the lease, and let the system handle the rest
  - zie 2y ago
    Yup, that's basically how Vault/Bao does it.
Quothling 2y ago
> How do you handle service account credentials in a good way? Passwordless. If someone can log into a service account then it's not secure. If you need direct access to systems then you grant temporary rights to individual users. To make this smooth you need to create a service to do it. Basically the flow would be for a user to request access and for the service to ask their direct manager (or whoever has the rights) for permission. I know it's common for organisations to let IT operations handle this, but this is a terrible practice. Your IT department will almost never be in a position where they are the ones who have authority to grant access to anything without manager permission, a permission they should basically ask for every time. Also it's a massive waste of time for everyone. Yes, I know it's extremely common to just let IT operations do it anyway, but well, you shouldn't.

karmakaze 2y ago

> the credentials of that service account Why do these accounts only have a single user/password? In any case, my answer would again be automation. Script the test, have the authorized process test out the service account on behalf of any employee who can create and run those tests.

crazygringo 2y ago
Because that's just how some products are set up. Not every external service account provides separate passwords for different employees, there's just a single corporate account that some certain number of people need to have access to. And automation isn't an answer to that. The question is how to share the password in the first place, not to automate what is done with it.
- Maxion 2y ago
  I've bumped into this with various API integrations to e.g. warehousing systems, ERPs, hosting providers and what not. The advice in this thread works great until you are on a project to integrate X API into Y project, and you need the admin dashboard. Now you have three developers who all need to share one account.

ethbr1 2y ago

You need to be able to automate 3 things: 1. Account pass retrieval 2. Account pass rotation 3. Account pass ref update (1) is how a user gets the pass when needed (normal process or break glass debug). (2) is how the pass rotates to an unknown value, automatically, after the user is done with it. (3) is how the new value gets updated in references, without the user knowing the new value. At the root of any solution are answers to those 3 needs.

zie 2y ago

The best way to handle service accounts is nobody knows the password. When X needs to troubleshoot, they change the password, do what needs to be done, then change it again afterwards, to some unknown value. It's a lot easier if you automate the password delivery to the service account. 1Password can do this with their CLI offering and Vault/OpenBAO can also do this. There are other password managers that can do similar things as well. With Vault/OpenBAO, for many services, it can handle password rotation and can even generate accounts(with appropriate permissions) for you, so you need access to Y service, Vault will create a temporary account. When the token expires, it will delete the account automatically. If you can't get there yet, then you limit the damage by limiting the shared password to a small set of people, use a password manager and as soon as any one of them leave the group, rotate the password.

jareklupinski 2y ago
> The best way to handle service accounts is nobody knows the password. When X needs to troubleshoot, they change the password, do what needs to be done, then change it again afterwards, to some unknown value. one way i've seen this is on a 'lease' system: your user requests access to use the account, the system logs your request and generates a random password for you, you log in and use the account for the duration of the lease, and let the system handle the rest
- zie 2y ago
  Yup, that's basically how Vault/Bao does it.

Quothling 2y ago

> How do you handle service account credentials in a good way? Passwordless. If someone can log into a service account then it's not secure. If you need direct access to systems then you grant temporary rights to individual users. To make this smooth you need to create a service to do it. Basically the flow would be for a user to request access and for the service to ask their direct manager (or whoever has the rights) for permission. I know it's common for organisations to let IT operations handle this, but this is a terrible practice. Your IT department will almost never be in a position where they are the ones who have authority to grant access to anything without manager permission, a permission they should basically ask for every time. Also it's a massive waste of time for everyone. Yes, I know it's extremely common to just let IT operations do it anyway, but well, you shouldn't.