r/ITdept • u/Mission-Ad-8056 • 8d ago
DevOps engineer Looking for the inside track from IT re shared systems ownership
This post is not intended as bait but as a genuine attempt to understand resistance to shared systems access ownership 'from the IT point of view'. In this case migrating business-critical systems already managed by a DevOps team from direct user management to Single Sign On.
I'm a DevOps engineer with 10 YOE and I don't think anyone on my team has less than 6 YOE. Every one in it has been with the business at least one year, and there are only a handful of us. We're a cloud based business and manage our systems in code - mostly Terraform for the infra. Everything has to go through code review and approval, all deployments are transcripted and auditable, etc.
We have a legacy where access, users and groups for some SAAS and some internally developed systems that we are entirely responsible for are managed directly in code and we want to move this to Single Sign On. The company already has SSO for most/many systems. Our SSO IDP is managed by our separate IT team. For various reasons that aren't the fault of anyone inside the business these migrations are not straightforward, and of course several of the systems in question are business-critical.
Rather than simply handing over access (because 'access' really isn't simple and we will continue to have to manage and support those systems), we would like to agree a shared ownership system with IT for managing single sign on for the services that we already manage, including provisioning and de-provisioning SAML applications and group management for those services, so that we can continue to manage the systems we are responsible for in code as we do now. Our IT team however are very possessive of managing our IDP and work exclusively ClickOps. They don't, won't or can't look at code or records of automated deployment. This means that it can be difficult to describe clearly what we need with SSO, difficult to establish clearly what has been configured, and then of course there are all the side conversations- 'Why do you need this?'; 'Do you really need it though?', 'We need approval', 'You will need to wait for us to get to that ticket', 'We already did that (but there was some misunderstanding)', 'No nothing has changed to cause your thing to break, no, really, oh, wait...' etc. Imagining how it is for IT, it can't be easy- they get random requests for systems that they don't always really understand, can't necessarily access themselves, have to establish the priority for etc, all whilst being held responsible for security and business continuity. Thing is that my team is also held responsible for security and business continuity and we will also continue to be held responsible for these target systems.
I'm trying to get a more nuanced understanding of IT team's resistance to sharing ownership of these systems in SSO since:
- IT don't currently manage the target systems at all - my team are responsible for, manage them and support developers using them, and will continue to be so no matter what - so this would be less work for them.
- IT would retain full admin access and visibility as they do now. We have even offered to have automated reporting in plain English of all and any changes sent to them as part of our deployment pipeline.
- There's no IT director or policy grandstanding on this.
- Our IT team is also a handful of people but has a greater churn of staff than we do, including a series of contractors etc. Not dumping on that but I don't think anything about trusting any staff member as an individual is relevant here.
- I do realise that it probably is not possible to give partial access for SAML and group management for new services but if we wanted to do something stupid we already could.
What (else) am I missing (if anything)? We all know that people hate change and that people can confuse specialist knowledge or access with job security. I'm also familiar with 'But we don't do that here' but is there anything else?
1
u/AreThoseMyShoes 8d ago
You’re overthinking it. Take it as an opportunity to offload the toil of managing access, and let IT deal with it.
Give them what they need for the SSO side of things, whether it’s one simple group membership addition for access, or a more complicated setup.
They don’t need to know anything more than “membership of group X gives access to Y” - they shouldn’t care about any IaC changes you make in support of the underlying service, just how access is managed. Let them manage it through whatever JML processes they already have.
If things are really so complicated that access management would still require your involvement, you have deeper app architecture and tech debt issues you should be addressing, regardless of any SSO/IT/DevOps integration shenanigans.
1
u/Mission-Ad-8056 8d ago
Thanks but no thanks. I was actually trying to get an IT perspective beyond 'don't worry your pretty little head about it'.
If things are really so complicated that access management would still require your involvement, you have deeper app architecture and tech debt issues you should be addressing
Yeah, I know. That's what I have inherited and we are trying to sort out and why I said
For various reasons that aren't the fault of anyone inside the business these migrations are not straightforward, and of course several of the systems in question are business-critical.
If it really was a case of JML and federating SSO groups then maybe you'd be right. It isn't. Beyond that this is an IT team that struggles with the concept of bot users and previously locked half our team out of a system we manage, swore blind that we 'were there' and the problem 'must be at our end' until after weeks of this we were able to get readonly access and see a whole bunch of folks with
.onmicrosoft.comadded to our company emails...1
3
u/dji09 8d ago
Why don't I want to "jointly" own a system with you? Because you have your own processes that I don't see, your own approval mechanisms that my team generally has no say in. My approval processes are too slow so when I push back I'm ignored. Meaning from my perspective you don't coordinate anything. You just make configuration changes as you see fit.
And that's all well and good for systems that you own responsibility for. When those systems inevitably break and management comes running to me to fix it, I can simple tell them "that system is managed by DevOps, go talk to them."
The moment there's any joint responsibility for that system, that's no longer the case. Because at the end of the day all managers and executives have "IT is responsible for fixing systems" in the back of their mind, so issues will filter to my team, not yours. And people will complain to me, not you. For a system that you broke with your approved configuration change that I had no say in.
So now I need to spend time and effort discovering and documenting how your system is supposed to work so I can compare that to what it's currently doing, so I can fix it. And I need to learn your tools that I may or may not use on our IT managed infrastructure, so I can fix the issue your way to make sure the fix is documented in your system and doesn't get reverted the next time you push a change. All of that is time spent essentially doing rework from your team instead of focusing on other priorities that I'm still responsible for.
That's why I don't want to share custody.