-1

I know this question is a little subjective. My intent is to just ask how typical large organizations setup their cloud permissions. I'm particularly interested in Azure implementations.

I'm a developer in a large healthcare company (20k+ employees 1-2k IT professionals). We have rolled out our own Azure implementation but have granted developers pretty much no permissions into the azure portal. If I need infrastructure for projects I need to submit a ticket to request it. Once I get the infrastructure I can do nothing to it in the portal. If I need to have some Azure Active Directory application roles created, or if I want to make a change to my app service (like enabling Managed Service Identities) I need to submit a ticket to our Cloud Intrastructure team. Is this typical or do other large organizations grant developers more privileges (especially in non production environments)?

From a developer's perspective our setup is madness. I end up writing powershell scripts and send them in tickets to infrastructure people (or sometimes to Active Directory Administrators) and they end up executing the scripts without understanding what they are doing.

I have a feeling this is probably an artifact of our companies culture, but maybe not. Is allowing developers 0 permissions in the azure portal a typical thing?

cobolstinks
  • 99
  • 1
  • How much control/access do you have of your on premises assets? Why would/should Azure assets be treated differently? Note that I'm asking your for your objective opinion. How do you think Azure assets be treated and is that different than on premises assets? If so, why? What is the justification? – joeqwerty Mar 24 '19 at 22:46
  • Good point we're locked done on premise as well. But part of the reasons I think were locked down on premise is because we don't have the tools available to consistently and reliably grant more permissions to none ops people. The azure portal is an excellent tool that we could open up in no prod environments to none ops people. – cobolstinks Mar 24 '19 at 23:49

1 Answers1

2

Although I have not experienced Azure implementations of that size, that sounds exactly like what would happen in a large, specialized/siloed, process heavy IT organization.

  • Make the case to the process owners that this is hurting your productivity in delivering solutions.
  • Review the processes and why they exist: what risks they mitigate and what expertise needs to be involved.
  • Propose a compromise, such as more access in a development environment, but stay hands off prod and test.
  • Find and build tools to document and execute the exact same changes in dev, test, and prod. "Infrastructure as code", if you want to call it that.
  • Build trust by helping execute changes accurately, maintaining stable environments.

You call it madness, others change control. When only the directory administrators can edit roles, that is a security point of control. Approval process for new infrastructure minimizes cost surprises when the bill arrives. Documenting changes is important to reference when inevitably something breaks and the cause is unknown.

Probably too heavy of a process for development environment, yes. Although, until know how good someone is at operations, I personally would be reluctant to trust them with test, let alone prod.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thanks good perspectives, I can understand the need for production to be locked down. It's just infurating to tell product owners we need to wait (let's say a month) to get a SQL azure environment spun up with a service account in dev. – cobolstinks Mar 24 '19 at 23:53
  • There just needs to be a middle ground here without stiffelling development – cobolstinks Mar 25 '19 at 00:02
  • Which is why I mentioned to bring up the possible reduction in delays, but also have a compromise plan acknowledging necessary process. – John Mahowald Mar 25 '19 at 05:04