4 ms·

Don't. Give them access to all systems they need with their own user/password. That way you can revoke them (if/when necessary) without disrupting everyone else

Don't. Give them access to all systems they need with their own user/password. That way you can revoke them (if/when necessary) without disrupting everyone else. Also automate as much as is reasonable, e.g. github access to push code to a dev branch, then enqueue merging of it. But a CI/CD pipeline does the actual deploy, the employee doesn't need to access any of the production systems. A very small number still will, but that's a much better situation. Give the employee 1Password to manage their own passwords.

worldsayshi 2y ago
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.
SkyPuncher 2y ago
Unfortunately, some services don’t allow this.
- lolinder 2y ago
  Ideally they would support SSO, but at a minimum any service that wants business customers will have accounts in some form. If they don't even have that then I would seriously second guess using them for anything in production. They're clearly not designed for businesses and can't be relied upon to not screw you up in serious ways.
  - crazygringo 2y ago
    > but at a minimum any service that wants business customers will have accounts in some form. I mean, that's just not true. Plenty of successful and widely used businesses out there provide a single account/password for their service at a client company, rather than for each human user at that client company. It's a common pattern even if you think it shouldn't be. And yes they are designed for businsses and have business customers. For a lot of products, it's just not conceptually necessary to have multiple users for an account, i.e. support for "teams". It's a convenience that might be on the roadmap and might get done eventually, or not at all. Especially because supporting complex sets of user credentials can be a major project, which means another important feature doesn't get done instead.
    - lolinder 2y ago
      > And yes they are designed for businsses and have business customers. What I'm saying is that by definition these aren't designed for businesses. They might have business customers, they might even think that that's where their primary market is, but they're not designed for businesses if they use an account model that is designed for single consumer. And if they can't have been bothered to put together an account system then what else didn't they bother doing? I'm not buying the idea that an account system is just too complicated and would eat up too much time. There are only a few extra moving parts (teams, very basic roles) for an enormous quality of life improvement for the company (this entire thread would be largely unnecessary if every product a business used supported at least basic account management).

worldsayshi 2y ago

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.

SkyPuncher 2y ago

Unfortunately, some services don’t allow this.

lolinder 2y ago
Ideally they would support SSO, but at a minimum any service that wants business customers will have accounts in some form. If they don't even have that then I would seriously second guess using them for anything in production. They're clearly not designed for businesses and can't be relied upon to not screw you up in serious ways.
- crazygringo 2y ago
  > but at a minimum any service that wants business customers will have accounts in some form. I mean, that's just not true. Plenty of successful and widely used businesses out there provide a single account/password for their service at a client company, rather than for each human user at that client company. It's a common pattern even if you think it shouldn't be. And yes they are designed for businsses and have business customers. For a lot of products, it's just not conceptually necessary to have multiple users for an account, i.e. support for "teams". It's a convenience that might be on the roadmap and might get done eventually, or not at all. Especially because supporting complex sets of user credentials can be a major project, which means another important feature doesn't get done instead.
  - lolinder 2y ago
    > And yes they are designed for businsses and have business customers. What I'm saying is that by definition these aren't designed for businesses. They might have business customers, they might even think that that's where their primary market is, but they're not designed for businesses if they use an account model that is designed for single consumer. And if they can't have been bothered to put together an account system then what else didn't they bother doing? I'm not buying the idea that an account system is just too complicated and would eat up too much time. There are only a few extra moving parts (teams, very basic roles) for an enormous quality of life improvement for the company (this entire thread would be largely unnecessary if every product a business used supported at least basic account management).