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?