4 ms·

Unfortunately what has been somewhat consistent for me during onboarding is that my manager did not bother to make sure I have the needed credentials and roles

by hbarka 5y ago

Unfortunately what has been somewhat consistent for me during onboarding is that my manager did not bother to make sure I have the needed credentials and roles in advance. Days and weeks were wasted where I had to fend for myself, against NIMBYist “owners” of said systems who were more afraid than helpful. You question why you were hired. “You’re a data /*/*? Oh I’m sorry I will just give you read-only access for now.” “You need access to that system to analyze data? I’m sorry but the your mgr has to approve and then security director.” “You’re a senior *?” I’m sorry we require you to be part of the sprint team first before <make up some shit>”. “Oh I should have added you to that <meeting/team folder/JIRA/Repo/DB/Cloud> but first let me give you some hurdles I can think of because you threaten my status.” This is onboarding. Your manager can do a better job getting this taken care of in advance instead of leaving you to slog through. Run if you see this kind of culture.

mattcwilson 5y ago
My experience as a manager has been frustratingly similar. For the same security and least-access reasons, I don’t have a view into the systems permissions tables for all of the tools that my team uses. I also don’t have a “definitely complete” list of what those tools even are, or what roles my current team members have in them. So when it comes to presenting IT with a new hire access request, often the best I can do is to say “please copy the access that person Y (another member of my team) has in system Z to a new account for person X” Because of audit regulations, I have to do this on a one-request-per-person-per-system basis. Bulk changes for a group of users, systems, or both are verboten. IMO, it feels like this is another area where no one is incentivized to own a holistic and efficient outcome. It’s not quite laziness, but it is a mountain of tedious and error prone tape cutting, compounded by information changing rapidly underneath in a way opaque to the people closest to the issue. I suspect that this could be a lot better in a world where “default roles and system permissions for those roles” is a centralized and crowd-sourced document. Like a terraform config. And then any time access needs change in a non-one-off way, you could tf apply the new roles table out to all the systems. Such is my dream, anyway
- bpicolo 5y ago
  Theoretically the goal of SSO systems, just hard in practice with inconsistent implementation and the SSO tax [0] [0]: https://sso.tax/ https://sso.tax/
  - mattcwilson 5y ago
    Maybe? I am not sure how much "role assignment" is handled as part of SSO vs. how often SSO is purely authentication and there's another app-tier layer that's doing authorization. "Role definition" is certainly app-tier, by ... uh... definition. I'm thinking of something more like a literal terraform config that treats roles as resource templates to be instantiated against human accounts. { template: "New SE", roles: [ { system: AWS-Live, role: ReadOnly }, { system: SonatypeNexus, role: ReadOnly } ... ] } And then you just do the equivalent of "tf apply 'New SE' joe@example.com" and a bunch of UX or backend automation updates permissions for Joe in all the things. And then you publish the role templates, and let your EMs, Sr. SEs, and other opinion-havers about roles start tuning/tweaking/extending/adding. With review and approval from Sec and IT. And then if there's some role definition change, you just roll it out like you would a single user.

by hbarka 5y ago

mattcwilson 5y ago

My experience as a manager has been frustratingly similar. For the same security and least-access reasons, I don’t have a view into the systems permissions tables for all of the tools that my team uses. I also don’t have a “definitely complete” list of what those tools even are, or what roles my current team members have in them. So when it comes to presenting IT with a new hire access request, often the best I can do is to say “please copy the access that person Y (another member of my team) has in system Z to a new account for person X” Because of audit regulations, I have to do this on a one-request-per-person-per-system basis. Bulk changes for a group of users, systems, or both are verboten. IMO, it feels like this is another area where no one is incentivized to own a holistic and efficient outcome. It’s not quite laziness, but it is a mountain of tedious and error prone tape cutting, compounded by information changing rapidly underneath in a way opaque to the people closest to the issue. I suspect that this could be a lot better in a world where “default roles and system permissions for those roles” is a centralized and crowd-sourced document. Like a terraform config. And then any time access needs change in a non-one-off way, you could tf apply the new roles table out to all the systems. Such is my dream, anyway

bpicolo 5y ago
Theoretically the goal of SSO systems, just hard in practice with inconsistent implementation and the SSO tax [0] [0]: https://sso.tax/ https://sso.tax/
- mattcwilson 5y ago
  Maybe? I am not sure how much "role assignment" is handled as part of SSO vs. how often SSO is purely authentication and there's another app-tier layer that's doing authorization. "Role definition" is certainly app-tier, by ... uh... definition. I'm thinking of something more like a literal terraform config that treats roles as resource templates to be instantiated against human accounts. { template: "New SE", roles: [ { system: AWS-Live, role: ReadOnly }, { system: SonatypeNexus, role: ReadOnly } ... ] } And then you just do the equivalent of "tf apply 'New SE' joe@example.com" and a bunch of UX or backend automation updates permissions for Joe in all the things. And then you publish the role templates, and let your EMs, Sr. SEs, and other opinion-havers about roles start tuning/tweaking/extending/adding. With review and approval from Sec and IT. And then if there's some role definition change, you just roll it out like you would a single user.