I’ve worked with Azure for a few years now, AWS and classic data centres for 15 years before that.
It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
I see a problem like granting */read in an innocuously named role and am left wondering if it was pragmatism, because figuring out least privilege was tough, or a junior who didn’t know better and was just trying to make progress.
I’m on a phone and can’t search git effectively, but I’d swear there was a comment or note on the golang implementation of msal saying that it used non-idiomatic go with no real support for many of the auth flows in v1 because it was written by an enthusiastic junior dev and released with little review. The modern version looks better, but I felt like I got a window into Azure back when I read that.
Building large services is hard, my hat is off that Microsoft is making it work, but sometimes we get to see that it’s just teams of developers doing it for them and those teams look a lot like the teams we work with every day. There’s no secret sauce, except that MS has the resources to iterate until the thing mostly works most of the time.
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination.
I've come to the same conclusion after dealing (and reporting) jankyness in both the Azure (ARM) API and especially the CLI. [0] is a nice issue I look at every once in a while. I think an installed az cli is now 700 MB+ of Python code and different bundled python versions...
Why do all these use Python? AWS, GCP, Azure, all three CLIs use Python; they're slow, bloated, heavy to install... what advantage does Python really offer here? You can't in any sensible way rely on it being installed (in your linked issue we see that they actually bundle it) so it's not even an 'easy' runtime.
Python takes up less than 16 MB on disk (python3.11-minimal + libpython3.11-stdlib on Debian) so whatever Microsoft did to make their Azure CLI package take up almost 700 MB, I don't think the language is the problem.
It might well be part of the problem. Certainly any language can be inefficient, especially in terms of size, if you don't pay attention (have certainly found this with Go recently). But as I said it's also slow (interpreting code, or dealing with cached versions of it) and it's not obvious to me why all three major cloud CLIs have chosen it over alternatives.
I don't understand the Python hate. What would they use instead?
Python is installed on most systems and easy to install when it's not. Only Azure is dumb enough to bundle it, and that was a complaint in the bug - there's no good reason to do so in this day and age.
The performance bottle neck in all three is usually the network communication - have you seen cases where the Python CLI app itself was using 100% of a CPU and slowing things down? I personally haven't.
Looking at the crazy way Azure packaged their CLI, it's hard to believe they weren't making it bloated on purpose.
And which Python are you talking about? I mean, Python3 is forward compatible but you SoL if you have the bad luck of having an older interpreter installed and you want to run a script which uses a new construct.
I don't understand why Windows people are completely okay having to install all kinds of crazy service packs and Visual C++ runtimes anytime they install anything, but then having to install Python seperately makes it a no-go.
Also, AWS is 10 years older than Rust, and C# only runs on Windows (at least it certainly only did when AWS was created, and is laughably more difficult to get running on Linux or OSX than Python).
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
You can say that for the APIs themselves. It's like every API call has 80% of the info I want, but the other 20% that logically belongs with that 80% has to come from multiple other API calls.
The one that annoys me on a daily basis is fetching the logs for a pipeline run. The endpoint is `_apis/build/builds/<id>/logs` and it returns a list of pipeline log objects without the task name that generated them. You get an object with these fields: `{"lineCount", "createdOn", "lastChangedOn", "id", "type", "url"}` but no mention of the pipeline stage that generated it.. whether it's the build step, test run, publishing stage, etc. And those ids change (for example if you re-run a failed job, the unit tests may have ID 4 from the first run, and ID 17 for the second try), so you can't just rely on that.
And the pipeline log viewer on the website is garbage. When you click the link to view the logs it doesn't show you the logs it's collected already but starts showing new logs from that point forward and even for that, sometimes it truncates output and will skip lines. Somehow they managed to make trawling through logs even worse than it would normally be.
The new Notepad would hang for minutes if you used it to open a large text file. It also stuttered when scrolling. It’s incredible to see something so low quality make it into a core operating system app release.
> a junior who didn’t know better and was just trying to make progress
While totally plausible, that's kinda besides the point IMO. This shows regardless of how it happened, they don't have sufficient test coverage of these roles. Meaning built-in roles cannot be trusted.
AWS documentation is similarly bad: I used to joke that it was all written down to remind the service team of something rather than as something that is useful for users to read in advance and understand the service.
Anecdotally - working with Azure has been hell on earth for me. Insanely unintuitive and buggy interface. Many cryptic errors preventing me from doing anything.
Microsoft doesn’t really respect their users because most of the users don’t decide by themselves to use Azure. Someone else make the decision for them. And it’s probably like that for many of their other products.
in the case of Azure, the users are the engineers tasked with implementing the infra
I'm not sure I've ever heard of a shop adopting Azure on pure engineering merit but my anecdata are hardly exhaustive. it tends to be forced for weird business reasons (retailers mistrusting Amazon, data residency requirements, sweetheart credit deal, CIO convinced by Azure rep over golf)
AWS and GCP started by engineers building products for engineers and later post success moved into enterprise sales (which AWS is doing well with, GCP not so much).
Azure came late and decided by decree that they needed a Cloud thing and so various business units came together and offered up a "strategy" for how they could re-brand and re-market what they had into a "unified offering".
And so you get things like Azure blob storage with fixed limits on performance per bucket. There's nothing cloud about it. Not so much leaky abstractions as a bucket of water labelled "cloud".
> AWS and GCP started by engineers building products for engineers and later post success moved into enterprise sales (which AWS is doing well with, GCP not so much).
I think that product managers are AWS' and GCP's unsung heroes. One of the best things about AWS is how in contrast everything is designed to integrate exceptionally well with everything in the AWS ecosystem, and all services are designed to be simple, kept simple, and kept backwards compatible even when subjected to major upgrades. Which are always seamless.
In contrast, can anyone explain why Azure has Table Storage but also Cosmos DB, and Cosmos DB is actually half a dozen storage services? Why isn't Table Storage also Cosmos DB, then? Table Storage shares SDKs with CosmosDB, too.
The same applies to messaging. You have Storage Queues, Service Bus queues, Event Hub, and Event Grid. Even when you ask Azure experts what's the difference between, say, Storage Queues and Service Bus Queues, the answer is never clear, simple, straight-forward, or understandable.
It's a mess, and those who have to deal with it are left to navigate this mess.
Yes it sucks and the documentation sucks even more. I think azure and whatever you call the google cloud configuration site are both so complicated because they're best for giant corporations with thousands of employees and many many roles in the organization with different privileges. However if you're just a single developer setting up something simple it's hellish.
It would be nice if they provided a simple setup configuration option for simple setups.
Quite honestly a single person working at a micro scale is not the target market for the hyperscalers. You're better served not going for managed services (and buying unmanaged services on the big clouds also doesn't make sense without needing the entire ecosystem around it).
Not from my experience. I've worked with all three of them. If one can stick with the web UI to provision permissions and the permissions required are simple/straightforward, Google Cloud (again, this is my personal opinion, so please take it with a grain of salt) is the most usable among the three.
BUT all three of them (AWS, Azure and GCP) have pros and cons, so you just have to spend a good amount of time learning their quirks.
AWS IAM isn't well designed, policy attachments all over the place making it near impossible to figure out what set of permissions you might actually have
As hair-splitting, its IAM can be well designed but the management tooling/observability can be lacking.
In my mind, "not well designed" would be "I cannot represent my security need in this policy language" versus the more common opinion "AWS IAM is a black box" means "I cannot understand why I am getting a 403"
GCP's IAM is, in this premise, not well designed because I cannot express ReadOnlyAccess in their policy language without having a constantly updating policy job, because they do not have wildcards in the Action as does AWS. Contrast `Action: ["s3:Get*"]` which would cheerfully include access to a future GetBucketV7 verb to GCP's "storage.buckets.get" which must always be specified, in full, and when storage2.buckets.get comes out, it's my job to find all references and patch them
There is similar issue with AWS. AWS provides a "ReadOnlyAccess" managed policy that has additional privileges that you probably don't want folks to have (e.g. can read S3 bucket content, not just see bucket names/key names). They recognized this and created a more limited "ViewOnlyAccess" that doesn't have access to content.
There's another common fix, which is to apply a permission boundary to IAM roles. This allows the use of generic policies like "ReadOnlyAccess" but can then be further downscoped to resources by tag (or other similar ABAC schemes)
You should not be using any of their managed policies, but creating your own. Using their own managed policies is a strong misunderstanding of how to use IAM.
(I used to work for AWS and am long Amazon stock. In no way do I speak for Amazon)
With Amazon, you are genuinely the customer. AWS may do many things in a bizarre or byzantine way, but it is constantly trying to be there for the developer in ways that many competitors in my opinion are not.
It is, without any question. Even of you work at a Microsoft shop, the benefits you get from vertical integration isn't that clear. Azure requires a far greater cognitive load to handle and to make matters worse ultimately experiences far more outages.
Coming from a Windows enterprise background, the UI for the most part makes sense and not something I find difficult to navigate (the original UI was awful). I know your sentiment is not uncommon, but I'm unable to share it.
I will agree, and this is a general Microsoft problem spanning back to the 90s, some error messages aren't useful what so ever. Others are clear and concise. I figure this is due to the different PGs following their own set of rules.
> Anecdotally - working with Azure has been hell on earth for me. Insanely unintuitive and buggy interface. Many cryptic errors preventing me from doing anything.
What pisses me off the most about Azure is now they designed it as the 90's view of what a cloud provider is. With Azure you don't just provision a VM or God forbid a web service. No no no. You need to provision an app service plan first, where you have to provision what computational resources you allocate to it, and then assign services and even gasp function-as-a-service apps. And even with FaaS stuff you don't just provision a handler. No, that would make too much sense. First you need to provision a function app running on your service plan, and you provision whatever azure functions you need as part of the function app. How much accidental complexity is that? Can't I just deploy an app or God forbid a function?
The same think applies to storage, but it's even worse. You get your storage account, and you need to providion a storage account to be able to provision one or more blob storage containers, azure tables, even simple queues. But wait, you need a storage account to store data in a nosql services, but if you opt for the other nosql service then that's an entirely different thing. For that you can simply go ahead and create an account. You can use the same SDK for both? That's nice. Wait, why do they have two nosql services?
Azure, man. It exists to make every single alternative look good.
You can provision an Azure Web Service (PaaS web server running IIS or whatever the Linux version runs) which provisions the computational resource, Azure App Service, as part of the deployment steps.
You certainly can do it in the way you've specified but I only see that as useful if you're provisioning multiple Web Services to point to a single App Service.
But to answer your question, yes you can "just" provision a Function or Web Service, the wizard walks you through it. The App Service behind the scenes is just details and not something you must interact with post-Function creation.
> You can provision an Azure Web Service (...) which provisions the computational resource, Azure App Service, as part of the deployment steps.
That's not a solution because deployment steps aren't a problem. The brain-dead aspect of Azure is how it forces users to handle the complexity of having to deal with provisioning and budgeting what computational resources used to run a set of web apps. This doesn't even buy isolation. If I'm paying for cloud services, why on earth should I concern myself with how much RAM I need to share across N apps? It's absolutely brain dead.
When I ran public sites each received it's own App Service, though they were provisioned via ARM template because that's what you do (or Terraform, etc) rather than get into the UI or manual CLI in an enterprise. All of these complaints you're bringing forth are a non-issue in a practical deployment.
You don't. You also do not have to share the same service plan with any other app service or function app. That's besides the point. The point is that Azure requires anyone who wants to run a god damned web service or even a single event handler to provision a bunch of infrastructure resources, just to be in a position to even consider deploying the thing.
I mean, you need to have both an Azure Service Plan and an Azure Storage Account to even consider deploying something serverless. Let that absurdity sink in.
In contrast, with AWS you just deploy the damned Lambda. That's it.
> (...) though they were provisioned via ARM template (...)
That is completely besides the point. It's irrelevant how any IaC offering turns any provisioning into a one-click affair. What's relevant is accidental complexity created by Azure for no reason at all. Go look at your ARM templates and count the number of resources you need to have there just to be able to run a single no-op event handler. It's stupid.
Quote: „Default hosting plan that provides true serverless hosting“
This one doesn’t require an app service plan.
Actually I like that offering, depending on your requirements you have several options to host your functions. That’s pretty great.
If they would offer just one kind of function app or one kind of storage solution people would complain that their very important edge case is not supported. For those simple requirements you can use cloudflare, vercel etc…
It requires a plan. You need to know what a plan is and what plan your azure functions are running on. Is it a consumption plan? Or is it a flex consumption plan?
I mean, you can run multiple function apps on the same plan. As a developer, you are required to know which plan a particular function app is running on, and be aware of the implications.
You open vscode, install the Azure Functions extensions, walk through the wizard to pick your programming language and write the code.
Then create and deploy it from vscode without ever leaving your IDE.
> You open vscode, install the Azure Functions extensions, walk through the wizard to pick your programming language and write the code. Then create and deploy it from vscode without ever leaving your IDE.
You are talking about something entirely different. Provisioning a function app is not the same as deploying the function app. How easy it is to upload a zip is immaterial to the discussion.
> The vscode extension can both provisions the resource as well as deploy it.
On top of having to have an Azure subscription, you need to provision:
- a resource group
- a service plan
- a function app
You do not get to skip those with azure.
And by the way, the only time anyone uses vscode to deploy an app, or even visual studio, is to work on personal projects or sandbox environments. Even so, you use the IDE to pick existing resources to deploy to.
All of this can easily be automated/cloned if it is something you do often. An RG is a collection of (hopefully) related resources. Plans and the App are provisioned together in the web UI wizard if that's the route you take.
I'm trying to educate you on the topic, but you seem to offer resistance.
I mean, I haven't even mentioned the fact that in order to be able to provision an azure function you are also forced to provision a storage account. As if the absurdity of the whole plan concept wasn't enough.
> All of this can easily be automated/cloned if it is something you do often.
Irrelevant. It's completely besides the point how you can automate deploying all those resources.
The whole point is that Azure follows an absurdly convoluted model that leaks forces users to manage many layers of low-level infrastructure details even when using services that supposedly follow serverless computing models. I mean, why on earth would anyone have to provision a storage account to be able to deploy an Azure Function? Absurd.
One thing I noticed about all of the public clouds is an insistence by small-scale users to avoid the user-friendly interface and go straight to the high scale templating or provisioning APIs because of a perception that that’s “more proper”.
You won’t get any benefits until you have dozens of instances of the same(ish) thing, and maybe not even then!
Especially in the dev stage it is perfectly fine to use the wizards in VS or VS Code.
The newer tooling around Aspire.NET and “azd up” makes this into true IaC with little effort.
Don’t overthink things!
PS: As a case in point I saw an entire team get bogged down for months trying to provision something through raw API calls that had ready-to-run script snippets in the docs and a Portal wizard that would have taken that team all of five minutes to click through… If they’re very slow with a mouse.
> That was not the point. Parent was complaining how complicated provisioning and deploying through the Azure portal was.
No, I wasn't. I was pointing out the fact that Azure follows an absurd, brain-dead model of what the cloud is, which needlessly and arbutrarily imposes layers of complexity without any reason.
Case in point: the concept of a service plan. It's straight up stupid to have a so-called cloud provider force customers to manage how many instances packing X RAM and Y vCPUs you need to have to run a function-as-a-service app, and then have to manage how that is shared with app services and other function apps.
Think about the backlash that AWS would experience if they somehow decided to force users to allocate EC2 instances to run lambda functions, and on top of that create another type of resource to group together lambdas to run on each EC2 instance.
To let the absurdity of that sink in, it's far easier, simpler, and much cheaper to just provision virtual private servers on a small cloud provider, stitch them together with a container orchestration service, and just deploy apps in there.
> Case in point: the concept of a service plan. It's straight up stupid to have a so-called cloud provider force customers to manage how many instances packing X RAM and Y vCPUs you need to have to run a function-as-a-service app, and then have to manage how that is shared with app services and other function apps.
You're not forced to, you can use a consumption plan.
> You're not forced to, you can use a consumption plan.
Pray tell, what do you think is relevant in citing how many plans you can pick and choose from to just run a simple function? I mean, are you trying to argue that instead of one type of plan, you have to choose another type of plan?
> What pisses me off the most about Azure is now they designed it as the 90's view of what a cloud provider is. With Azure you don't just provision a VM or God forbid a web service. No no no. You need to provision an app service plan first
What's funny is you're completely backwards here. Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2. Azure started as PaaS first and AWS started as IaaS first and that fingerprint is still all over their products. Building everything in a VM is the most expensive and naive way to adopt the cloud. It's the main reason why complexity and costs blow up. You're building in the cloud wrong and somehow seemed to have missed that a consumption based Function app is the default option and doesn't require an App Service Plan.
> What's funny is you're completely backwards here. Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2. Azure started as PaaS first and AWS started as IaaS first and that fingerprint is still all over their products.
Irrelevant. I don't care about either history or revisionism. I care about deploying apps/functions. In AWS each lambda function is a standalone resource, whereas in AWS you need to 1) provisional an app service plan, 2) deploy a function app on said service plan, 3) deploy the actual function. It's nuts.
Same goes for storage. While in AWS you just go ahead and create a S3 bucket, on Azures you have to providion storage accounts and then provision a blob storage container.
> Building everything in a VM is the most expensive and naive way to adopt the cloud.
Azure is more expensive, harder to manage, even more impossible to estimate costs. Making claims about cost as if it makes Azure look good sounds completely crazy.
You lie about or cannot figure out basic things in Azure like creating a Function without an App Service Plan. I cannot take anything you say at this point seriously. You're just coming across jaded and spreading misinformation.
> You lie about or cannot figure out basic things in Azure like creating a Function without an App Service Plan.
I recommend you spend a few minutes going through an intro tutorial on Azure Functions. A key topic on Azure Functions 101 is the concept of a plan and how to pick a hosting option. You can start by reading this link:
Once you read this link, you'll be aware that even in their so-called serverless plan that follows a "serverless billing model" you still have a plan tucked away where you can run multiple function apps in if you really want to.
Even if you pretend this doesn't exist, you need to ask yourself what is a plan and what does it matter to you and why do you care. Do you think that picking a plan does not factor as a concern in Azure?
>Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2
You must be joking!
I was looking a various Container Registry products and looked up Azure's recently. It has the following limits (On the premium SKU!):
50Mbps upload, 100Mbps down
What sort of a cloud product has limits like this! What a clown show.
> As noted, those are minimum limits. If there's a clown show, it's you who is hosting it.
Do they specify ay SLA other than the minimums? If not, I'm sorry to tell you, but they only offer the minimum and anything over that is a pleasant surprise.
This is from a few years ago but nothing seems to have changed. A cursory search of the Wiz blog with "Azure" reveals so many horrific (cross tenant, trivial to exploit) security vulnerabilities it's hard to imagine many people at Azure care about security. And that's just from one group of security researchers, from Wiz, there are others such as OP.
Bizarre vulnerability, unprofessional behavior from Microsoft to leave it open for so long and let Azure organization carry this out on the expense of security.
Azure identity is so bad. It's like they tried to build it on the original 1998 implementation of LDAP or whatever. Roles fucking inherit??? Like are you kidding me?
> Azure identity is so bad. It's like they tried to build it on the original 1998 implementation of LDAP or whatever.
I think that Azure AD is literally built on top of Active Directory. That's what you need to do if your goal is to help your customers, who already usd Active Directory, to seamlessly onboard onto their authentication system.
If you stop and think for a moment, you'd understand that it would be absurd not to do that. You have an army of institutional clients already using AD for everything. Are you going to force them to onboard onto another auth system after convincing them that AD suited all their needs?
Anyhow, they seem to try to distance themselves with their rebranding to Entra.
> Roles fucking inherit??? Like are you kidding me?
It definitely is built on AD in some form on the backend, just like Exchange Online is built on Exchange, and I believe EXO has its own AD infrastructure for each tenant that you sometimes have to wait for things to replicate to.
yes i know the history and excuse me for misnaming, but AD came out in 1998 IIRC whenever i hate-researched it. and it makes perfect sense for a business to do that but it is a terrible engineering platform because of that. what you said was my exact thought process the first time i encountered that tragedy, and that doesn't make it right or good. and now the enterprise businesses waste a lot of money in time spent paying engineers to work with the frakenstein.
This. Also try managing Gitlab permissions across a large org with lots of teams and lots of projects. Inheritance might seem like a good idea but it pollutes the hell out of everything once you're 3 levels deep in a org. I wrote some python scripts to generate a JSON dump of the whole org and from digging into it, some people have 30 different Access paths for some projects. Try locking that down without special tools.
> Lower levels inherit role permissions from higher levels...When you assign a role at a parent scope, those permissions are inherited to the child scopes
i designed an extremely tightly scoped managed identity to do a job. my azure admin created the resources, and now that identity shows an inheritance chain that tracks all the way to that admin (aka a very privileged identity). which seems insane.
i tested the identity to make sure it couldn't do privilege escalation...still, wtf? it might be my own fault where i'm doing something wrong, but that shouldn't even be possible for somebody to create a managed identity that would inherit from other identities. i don't trust that it's ok and i shouldn't be spending time figuring out if it is, i expect tightly scoped identities to just work...
Okay. Then I'll lay it out: there is no inheritance at all. An identity does not inherit roles and it certainly does not inherit other identities. You are misinterpreting something you saw. However, without further details, a more targeted answer is not possible. I did not want to write a blanket statement like that because it is very condescending and hostile. Sorry about that.
You may have seen the identity's IAM page. It does not show roles assigned to the identity.
> Lower levels inherit role permissions from higher levels...When you assign a role at a parent scope, those permissions are inherited to the child scopes
so i guess this what you said is confidently wrong lmao like you couldn't even be more wrong:
> Then I'll lay it out: there is no inheritance at all. An identity does not inherit roles and it certainly does not inherit other identities.
i misspoke calling it "identity inheritance" and not "scope inheritance" tho my first comment said "role inheritance" but the fact that there is any sort of inheritance involved at all with my rbac roles is very poor design decision. and the fact that i can misunderstand this and spend hours of company time trying to understand it, and still failing....when this should be an intuitive, 101-level thing for cloud design. but nah i gotta spend time going through like ten different docs piecing together knowledge and pentest my own work and also argue with some guy on the internet who called himself adept at azure and doesn't know this either (which further proves my point!)
The so-called "lower levels" inherit role permissions (or role assignments, if you will), which is something else entirely. Furthermore I'd say this is both expected and necessary to effectively administer permissions in organizations. Assigning permissions (via roles or otherwise) on every single object is not feasible. Inheritance is required. It works similarly to NTFS ACLs.
What I wrote is, in fact, accurate. An identity cannot inherit a role. It is simply impossible. What would it inherit from? The identity does not actually exist where it appears in the control plane (ie. in a resource group). It exists in Entra ID (formerly Azure AD).
There is but one possibility for a newly created identity to actually have roles assignments: Automation via policy. Now that I think about it, there might be another: assigning roles to special groups like "Authenticated users".
ok so now it's a semantic debate. love that... i hope this knowledge that i shared is useful to you in the future, so you can avoid dumb ass RBAC inheritance footguns
I think this confusion is exactly the problem.
“Roles inherit” is one of those Azure things that looks simple in docs but ends up creating hidden privilege sprawl in real environments. I’ve seen teams argue for hours about what gets inherited, what doesn’t, and who has access to what, just because a single assignment at the wrong scope can fan out across everything.
I'll take this opportunity to remind anyone on Azure that if you enable service endpoints on a subnet without applying service endpoint policies, anyone with the resourceid of an affected subnet can silently backdoor your network. Your NSGs do not matter for service endpoints.
This is crazy. Using HTTP methods to enforce API permissions? Only Microsoft could do something this lazy.
No wonder their own developers are getting confused...
It’s a combination of scope, resource types/operations and action type (similar to HTTP method, but somewhat normalized). Not that different from most ACL based systems.
The main problem raised by the article is a governance failure.
I’ve worked with Azure for a few years now, AWS and classic data centres for 15 years before that.
It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
I see a problem like granting */read in an innocuously named role and am left wondering if it was pragmatism, because figuring out least privilege was tough, or a junior who didn’t know better and was just trying to make progress.
I’m on a phone and can’t search git effectively, but I’d swear there was a comment or note on the golang implementation of msal saying that it used non-idiomatic go with no real support for many of the auth flows in v1 because it was written by an enthusiastic junior dev and released with little review. The modern version looks better, but I felt like I got a window into Azure back when I read that.
Building large services is hard, my hat is off that Microsoft is making it work, but sometimes we get to see that it’s just teams of developers doing it for them and those teams look a lot like the teams we work with every day. There’s no secret sauce, except that MS has the resources to iterate until the thing mostly works most of the time.
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination.
I've come to the same conclusion after dealing (and reporting) jankyness in both the Azure (ARM) API and especially the CLI. [0] is a nice issue I look at every once in a while. I think an installed az cli is now 700 MB+ of Python code and different bundled python versions...
[0]: https://github.com/Azure/azure-cli/issues/7387
It’s legitimately fun to see people gaining hope something would happen about this and then losing hope, again and again. Thanks for the laugh.
This is how you can tell that people doing systems work aren’t running the sdk project. A gig dependency for a few python scripts is hard to swallow.
Why do all these use Python? AWS, GCP, Azure, all three CLIs use Python; they're slow, bloated, heavy to install... what advantage does Python really offer here? You can't in any sensible way rely on it being installed (in your linked issue we see that they actually bundle it) so it's not even an 'easy' runtime.
Python takes up less than 16 MB on disk (python3.11-minimal + libpython3.11-stdlib on Debian) so whatever Microsoft did to make their Azure CLI package take up almost 700 MB, I don't think the language is the problem.
They bundle versioned API schemas....looooots of them.
It would be a garbage fire in any language
It might well be part of the problem. Certainly any language can be inefficient, especially in terms of size, if you don't pay attention (have certainly found this with Go recently). But as I said it's also slow (interpreting code, or dealing with cached versions of it) and it's not obvious to me why all three major cloud CLIs have chosen it over alternatives.
I don't understand the Python hate. What would they use instead?
Python is installed on most systems and easy to install when it's not. Only Azure is dumb enough to bundle it, and that was a complaint in the bug - there's no good reason to do so in this day and age.
The performance bottle neck in all three is usually the network communication - have you seen cases where the Python CLI app itself was using 100% of a CPU and slowing things down? I personally haven't.
Looking at the crazy way Azure packaged their CLI, it's hard to believe they weren't making it bloated on purpose.
> Python is installed on most systems (...)
Not on Windows.
And which Python are you talking about? I mean, Python3 is forward compatible but you SoL if you have the bad luck of having an older interpreter installed and you want to run a script which uses a new construct.
I don't understand why Windows people are completely okay having to install all kinds of crazy service packs and Visual C++ runtimes anytime they install anything, but then having to install Python seperately makes it a no-go.
A type safe and memory safe language, like rust? Or their own c# perhaps?
Python is a memory and typesafe language.
Also, AWS is 10 years older than Rust, and C# only runs on Windows (at least it certainly only did when AWS was created, and is laughably more difficult to get running on Linux or OSX than Python).
> Python is a ... typesafe language.
You're funny
> is laughably more difficult to get running on Linux or OSX than Python).
$(dotnet publish) <https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...> is the way they solve that problem in modern .net
And, unlike the scripting language you mentioned, most of the languages on the CLR actually are statically typed
> $(dotnet publish) <https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...> is the way they solve that problem in modern .net
That may work now, but it didn't exist when AWS was started.
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
You can say that for the APIs themselves. It's like every API call has 80% of the info I want, but the other 20% that logically belongs with that 80% has to come from multiple other API calls.
The one that annoys me on a daily basis is fetching the logs for a pipeline run. The endpoint is `_apis/build/builds/<id>/logs` and it returns a list of pipeline log objects without the task name that generated them. You get an object with these fields: `{"lineCount", "createdOn", "lastChangedOn", "id", "type", "url"}` but no mention of the pipeline stage that generated it.. whether it's the build step, test run, publishing stage, etc. And those ids change (for example if you re-run a failed job, the unit tests may have ID 4 from the first run, and ID 17 for the second try), so you can't just rely on that.
And the pipeline log viewer on the website is garbage. When you click the link to view the logs it doesn't show you the logs it's collected already but starts showing new logs from that point forward and even for that, sometimes it truncates output and will skip lines. Somehow they managed to make trawling through logs even worse than it would normally be.
The new Notepad would hang for minutes if you used it to open a large text file. It also stuttered when scrolling. It’s incredible to see something so low quality make it into a core operating system app release.
> a junior who didn’t know better and was just trying to make progress
While totally plausible, that's kinda besides the point IMO. This shows regardless of how it happened, they don't have sufficient test coverage of these roles. Meaning built-in roles cannot be trusted.
AWS documentation is similarly bad: I used to joke that it was all written down to remind the service team of something rather than as something that is useful for users to read in advance and understand the service.
Anecdotally - working with Azure has been hell on earth for me. Insanely unintuitive and buggy interface. Many cryptic errors preventing me from doing anything.
Microsoft doesn’t really respect their users because most of the users don’t decide by themselves to use Azure. Someone else make the decision for them. And it’s probably like that for many of their other products.
How does this not apply to - insert any product - in an enterprise space? With rare exceptions, users don't decide which software they use.
in the case of Azure, the users are the engineers tasked with implementing the infra
I'm not sure I've ever heard of a shop adopting Azure on pure engineering merit but my anecdata are hardly exhaustive. it tends to be forced for weird business reasons (retailers mistrusting Amazon, data residency requirements, sweetheart credit deal, CIO convinced by Azure rep over golf)
You’re right. It’s the embodiment of enterprise software sales. But some how AWS and GCP do it a bit better.
AWS and GCP started by engineers building products for engineers and later post success moved into enterprise sales (which AWS is doing well with, GCP not so much).
Azure came late and decided by decree that they needed a Cloud thing and so various business units came together and offered up a "strategy" for how they could re-brand and re-market what they had into a "unified offering".
And so you get things like Azure blob storage with fixed limits on performance per bucket. There's nothing cloud about it. Not so much leaky abstractions as a bucket of water labelled "cloud".
> AWS and GCP started by engineers building products for engineers and later post success moved into enterprise sales (which AWS is doing well with, GCP not so much).
I think that product managers are AWS' and GCP's unsung heroes. One of the best things about AWS is how in contrast everything is designed to integrate exceptionally well with everything in the AWS ecosystem, and all services are designed to be simple, kept simple, and kept backwards compatible even when subjected to major upgrades. Which are always seamless.
In contrast, can anyone explain why Azure has Table Storage but also Cosmos DB, and Cosmos DB is actually half a dozen storage services? Why isn't Table Storage also Cosmos DB, then? Table Storage shares SDKs with CosmosDB, too.
The same applies to messaging. You have Storage Queues, Service Bus queues, Event Hub, and Event Grid. Even when you ask Azure experts what's the difference between, say, Storage Queues and Service Bus Queues, the answer is never clear, simple, straight-forward, or understandable.
It's a mess, and those who have to deal with it are left to navigate this mess.
That probably explains why all enterprise software sucks.
Yes it sucks and the documentation sucks even more. I think azure and whatever you call the google cloud configuration site are both so complicated because they're best for giant corporations with thousands of employees and many many roles in the organization with different privileges. However if you're just a single developer setting up something simple it's hellish.
It would be nice if they provided a simple setup configuration option for simple setups.
Quite honestly a single person working at a micro scale is not the target market for the hyperscalers. You're better served not going for managed services (and buying unmanaged services on the big clouds also doesn't make sense without needing the entire ecosystem around it).
Is AWS any better? (Genuine question)
Not from my experience. I've worked with all three of them. If one can stick with the web UI to provision permissions and the permissions required are simple/straightforward, Google Cloud (again, this is my personal opinion, so please take it with a grain of salt) is the most usable among the three.
BUT all three of them (AWS, Azure and GCP) have pros and cons, so you just have to spend a good amount of time learning their quirks.
AWS IAM is very very well designed. They clearly have some sort of internal security & architecture review process that works.
AWS IAM isn't well designed, policy attachments all over the place making it near impossible to figure out what set of permissions you might actually have
and too much string to hang yourself with
As hair-splitting, its IAM can be well designed but the management tooling/observability can be lacking.
In my mind, "not well designed" would be "I cannot represent my security need in this policy language" versus the more common opinion "AWS IAM is a black box" means "I cannot understand why I am getting a 403"
GCP's IAM is, in this premise, not well designed because I cannot express ReadOnlyAccess in their policy language without having a constantly updating policy job, because they do not have wildcards in the Action as does AWS. Contrast `Action: ["s3:Get*"]` which would cheerfully include access to a future GetBucketV7 verb to GCP's "storage.buckets.get" which must always be specified, in full, and when storage2.buckets.get comes out, it's my job to find all references and patch them
There is similar issue with AWS. AWS provides a "ReadOnlyAccess" managed policy that has additional privileges that you probably don't want folks to have (e.g. can read S3 bucket content, not just see bucket names/key names). They recognized this and created a more limited "ViewOnlyAccess" that doesn't have access to content.
There's another common fix, which is to apply a permission boundary to IAM roles. This allows the use of generic policies like "ReadOnlyAccess" but can then be further downscoped to resources by tag (or other similar ABAC schemes)
You should not be using any of their managed policies, but creating your own. Using their own managed policies is a strong misunderstanding of how to use IAM.
Downvoting without discussion? That’s not critique, that’s cowardice. Tell me what is wrong about this factual statement.
(I used to work for AWS and am long Amazon stock. In no way do I speak for Amazon)
With Amazon, you are genuinely the customer. AWS may do many things in a bizarre or byzantine way, but it is constantly trying to be there for the developer in ways that many competitors in my opinion are not.
be there for the customer on AWS means adding another half baked config option that now all future users have to think about if they will need it
> Is AWS any better? (Genuine question)
It is, without any question. Even of you work at a Microsoft shop, the benefits you get from vertical integration isn't that clear. Azure requires a far greater cognitive load to handle and to make matters worse ultimately experiences far more outages.
Coming from a Windows enterprise background, the UI for the most part makes sense and not something I find difficult to navigate (the original UI was awful). I know your sentiment is not uncommon, but I'm unable to share it.
I will agree, and this is a general Microsoft problem spanning back to the 90s, some error messages aren't useful what so ever. Others are clear and concise. I figure this is due to the different PGs following their own set of rules.
> Anecdotally - working with Azure has been hell on earth for me. Insanely unintuitive and buggy interface. Many cryptic errors preventing me from doing anything.
What pisses me off the most about Azure is now they designed it as the 90's view of what a cloud provider is. With Azure you don't just provision a VM or God forbid a web service. No no no. You need to provision an app service plan first, where you have to provision what computational resources you allocate to it, and then assign services and even gasp function-as-a-service apps. And even with FaaS stuff you don't just provision a handler. No, that would make too much sense. First you need to provision a function app running on your service plan, and you provision whatever azure functions you need as part of the function app. How much accidental complexity is that? Can't I just deploy an app or God forbid a function?
The same think applies to storage, but it's even worse. You get your storage account, and you need to providion a storage account to be able to provision one or more blob storage containers, azure tables, even simple queues. But wait, you need a storage account to store data in a nosql services, but if you opt for the other nosql service then that's an entirely different thing. For that you can simply go ahead and create an account. You can use the same SDK for both? That's nice. Wait, why do they have two nosql services?
Azure, man. It exists to make every single alternative look good.
You can provision an Azure Web Service (PaaS web server running IIS or whatever the Linux version runs) which provisions the computational resource, Azure App Service, as part of the deployment steps.
You certainly can do it in the way you've specified but I only see that as useful if you're provisioning multiple Web Services to point to a single App Service.
But to answer your question, yes you can "just" provision a Function or Web Service, the wizard walks you through it. The App Service behind the scenes is just details and not something you must interact with post-Function creation.
> You can provision an Azure Web Service (...) which provisions the computational resource, Azure App Service, as part of the deployment steps.
That's not a solution because deployment steps aren't a problem. The brain-dead aspect of Azure is how it forces users to handle the complexity of having to deal with provisioning and budgeting what computational resources used to run a set of web apps. This doesn't even buy isolation. If I'm paying for cloud services, why on earth should I concern myself with how much RAM I need to share across N apps? It's absolutely brain dead.
You don't have to share anything across apps.
When I ran public sites each received it's own App Service, though they were provisioned via ARM template because that's what you do (or Terraform, etc) rather than get into the UI or manual CLI in an enterprise. All of these complaints you're bringing forth are a non-issue in a practical deployment.
> You don't have to share anything across apps.
You don't. You also do not have to share the same service plan with any other app service or function app. That's besides the point. The point is that Azure requires anyone who wants to run a god damned web service or even a single event handler to provision a bunch of infrastructure resources, just to be in a position to even consider deploying the thing.
I mean, you need to have both an Azure Service Plan and an Azure Storage Account to even consider deploying something serverless. Let that absurdity sink in.
In contrast, with AWS you just deploy the damned Lambda. That's it.
> (...) though they were provisioned via ARM template (...)
That is completely besides the point. It's irrelevant how any IaC offering turns any provisioning into a one-click affair. What's relevant is accidental complexity created by Azure for no reason at all. Go look at your ARM templates and count the number of resources you need to have there just to be able to run a single no-op event handler. It's stupid.
They have a Azure Function Serverless Offering called consumption plan: https://learn.microsoft.com/en-gb/azure/azure-functions/func...
Quote: „Default hosting plan that provides true serverless hosting“
This one doesn’t require an app service plan.
Actually I like that offering, depending on your requirements you have several options to host your functions. That’s pretty great.
If they would offer just one kind of function app or one kind of storage solution people would complain that their very important edge case is not supported. For those simple requirements you can use cloudflare, vercel etc…
> This one doesn’t require an app service plan.
It requires a plan. You need to know what a plan is and what plan your azure functions are running on. Is it a consumption plan? Or is it a flex consumption plan?
I mean, you can run multiple function apps on the same plan. As a developer, you are required to know which plan a particular function app is running on, and be aware of the implications.
You see how brain dead it is?
Yeah that, and in Azure OpenAI you have to create a separate deployment for each model you want to use.
You can just deploy a function.
You open vscode, install the Azure Functions extensions, walk through the wizard to pick your programming language and write the code. Then create and deploy it from vscode without ever leaving your IDE.
> You open vscode, install the Azure Functions extensions, walk through the wizard to pick your programming language and write the code. Then create and deploy it from vscode without ever leaving your IDE.
You are talking about something entirely different. Provisioning a function app is not the same as deploying the function app. How easy it is to upload a zip is immaterial to the discussion.
The vscode extension can both provisions the resource as well as deploy it.
Edit: And yes, it will create every resource it needs if you want to, except for the subscription.
> The vscode extension can both provisions the resource as well as deploy it.
On top of having to have an Azure subscription, you need to provision:
- a resource group
- a service plan
- a function app
You do not get to skip those with azure.
And by the way, the only time anyone uses vscode to deploy an app, or even visual studio, is to work on personal projects or sandbox environments. Even so, you use the IDE to pick existing resources to deploy to.
You're really trying, aren't you :-)
All of this can easily be automated/cloned if it is something you do often. An RG is a collection of (hopefully) related resources. Plans and the App are provisioned together in the web UI wizard if that's the route you take.
> You're really trying, aren't you :-)
I'm trying to educate you on the topic, but you seem to offer resistance.
I mean, I haven't even mentioned the fact that in order to be able to provision an azure function you are also forced to provision a storage account. As if the absurdity of the whole plan concept wasn't enough.
> All of this can easily be automated/cloned if it is something you do often.
Irrelevant. It's completely besides the point how you can automate deploying all those resources.
The whole point is that Azure follows an absurdly convoluted model that leaks forces users to manage many layers of low-level infrastructure details even when using services that supposedly follow serverless computing models. I mean, why on earth would anyone have to provision a storage account to be able to deploy an Azure Function? Absurd.
I've provisioned many Azure Functions apps; there's nothing you can educate me on, here.
Why do you care about a storage account so much?
https://learn.microsoft.com/en-us/azure/azure-functions/func...
Since you didn't know about the [Flex] Consumption plan, there's your education.
And as to why they require a storage account:
https://learn.microsoft.com/en-us/azure/azure-functions/stor...
Wallah, education!
Which is exactly the opposite of how to effectively manage applications, code, and change at any scale beyond a home project.
One thing I noticed about all of the public clouds is an insistence by small-scale users to avoid the user-friendly interface and go straight to the high scale templating or provisioning APIs because of a perception that that’s “more proper”.
You won’t get any benefits until you have dozens of instances of the same(ish) thing, and maybe not even then!
Especially in the dev stage it is perfectly fine to use the wizards in VS or VS Code.
The newer tooling around Aspire.NET and “azd up” makes this into true IaC with little effort.
Don’t overthink things!
PS: As a case in point I saw an entire team get bogged down for months trying to provision something through raw API calls that had ready-to-run script snippets in the docs and a Portal wizard that would have taken that team all of five minutes to click through… If they’re very slow with a mouse.
That was not the point. Parent was complaining how complicated provisioning and deploying through the Azure portal was.
At scale you'd IaC such as Bicep.
> That was not the point. Parent was complaining how complicated provisioning and deploying through the Azure portal was.
No, I wasn't. I was pointing out the fact that Azure follows an absurd, brain-dead model of what the cloud is, which needlessly and arbutrarily imposes layers of complexity without any reason.
Case in point: the concept of a service plan. It's straight up stupid to have a so-called cloud provider force customers to manage how many instances packing X RAM and Y vCPUs you need to have to run a function-as-a-service app, and then have to manage how that is shared with app services and other function apps.
Think about the backlash that AWS would experience if they somehow decided to force users to allocate EC2 instances to run lambda functions, and on top of that create another type of resource to group together lambdas to run on each EC2 instance.
To let the absurdity of that sink in, it's far easier, simpler, and much cheaper to just provision virtual private servers on a small cloud provider, stitch them together with a container orchestration service, and just deploy apps in there.
> Case in point: the concept of a service plan. It's straight up stupid to have a so-called cloud provider force customers to manage how many instances packing X RAM and Y vCPUs you need to have to run a function-as-a-service app, and then have to manage how that is shared with app services and other function apps.
You're not forced to, you can use a consumption plan.
https://azure.microsoft.com/en-us/pricing/details/functions/...
> You're not forced to, you can use a consumption plan.
Pray tell, what do you think is relevant in citing how many plans you can pick and choose from to just run a simple function? I mean, are you trying to argue that instead of one type of plan, you have to choose another type of plan?
The consumption plan is the default plan, so technically you don't have to choose anything, just go with the defaults.
But it disproves your point that you're "forced" to have an app service plan.
At this point you're simply arguing to argue after having been shown to be incorrect multiple times. Good luck.
> What pisses me off the most about Azure is now they designed it as the 90's view of what a cloud provider is. With Azure you don't just provision a VM or God forbid a web service. No no no. You need to provision an app service plan first
What's funny is you're completely backwards here. Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2. Azure started as PaaS first and AWS started as IaaS first and that fingerprint is still all over their products. Building everything in a VM is the most expensive and naive way to adopt the cloud. It's the main reason why complexity and costs blow up. You're building in the cloud wrong and somehow seemed to have missed that a consumption based Function app is the default option and doesn't require an App Service Plan.
> What's funny is you're completely backwards here. Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2. Azure started as PaaS first and AWS started as IaaS first and that fingerprint is still all over their products.
Irrelevant. I don't care about either history or revisionism. I care about deploying apps/functions. In AWS each lambda function is a standalone resource, whereas in AWS you need to 1) provisional an app service plan, 2) deploy a function app on said service plan, 3) deploy the actual function. It's nuts.
Same goes for storage. While in AWS you just go ahead and create a S3 bucket, on Azures you have to providion storage accounts and then provision a blob storage container.
> Building everything in a VM is the most expensive and naive way to adopt the cloud.
Azure is more expensive, harder to manage, even more impossible to estimate costs. Making claims about cost as if it makes Azure look good sounds completely crazy.
You lie about or cannot figure out basic things in Azure like creating a Function without an App Service Plan. I cannot take anything you say at this point seriously. You're just coming across jaded and spreading misinformation.
> You lie about or cannot figure out basic things in Azure like creating a Function without an App Service Plan.
I recommend you spend a few minutes going through an intro tutorial on Azure Functions. A key topic on Azure Functions 101 is the concept of a plan and how to pick a hosting option. You can start by reading this link:
https://learn.microsoft.com/en-us/azure/azure-functions/func...
Once you read this link, you'll be aware that even in their so-called serverless plan that follows a "serverless billing model" you still have a plan tucked away where you can run multiple function apps in if you really want to.
Even if you pretend this doesn't exist, you need to ask yourself what is a plan and what does it matter to you and why do you care. Do you think that picking a plan does not factor as a concern in Azure?
>Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2
You must be joking!
I was looking a various Container Registry products and looked up Azure's recently. It has the following limits (On the premium SKU!): 50Mbps upload, 100Mbps down
What sort of a cloud product has limits like this! What a clown show.
The footnote points out that those are minimum limits.
https://learn.microsoft.com/en-us/azure/container-registry/c...
As noted, those are minimum limits. If there's a clown show, it's you who is hosting it.
> As noted, those are minimum limits. If there's a clown show, it's you who is hosting it.
Do they specify ay SLA other than the minimums? If not, I'm sorry to tell you, but they only offer the minimum and anything over that is a pleasant surprise.
This is par for the course for Azure. Their security posture is genuinely terrifyingly lackluster.
https://www.lastweekinaws.com/blog/azures_vulnerabilities_ar...
This is from a few years ago but nothing seems to have changed. A cursory search of the Wiz blog with "Azure" reveals so many horrific (cross tenant, trivial to exploit) security vulnerabilities it's hard to imagine many people at Azure care about security. And that's just from one group of security researchers, from Wiz, there are others such as OP.
Bizarre vulnerability, unprofessional behavior from Microsoft to leave it open for so long and let Azure organization carry this out on the expense of security.
Azure identity is so bad. It's like they tried to build it on the original 1998 implementation of LDAP or whatever. Roles fucking inherit??? Like are you kidding me?
> Azure identity is so bad. It's like they tried to build it on the original 1998 implementation of LDAP or whatever.
I think that Azure AD is literally built on top of Active Directory. That's what you need to do if your goal is to help your customers, who already usd Active Directory, to seamlessly onboard onto their authentication system.
If you stop and think for a moment, you'd understand that it would be absurd not to do that. You have an army of institutional clients already using AD for everything. Are you going to force them to onboard onto another auth system after convincing them that AD suited all their needs?
Anyhow, they seem to try to distance themselves with their rebranding to Entra.
> Roles fucking inherit??? Like are you kidding me?
What do you think is wrong with that?
It definitely is built on AD in some form on the backend, just like Exchange Online is built on Exchange, and I believe EXO has its own AD infrastructure for each tenant that you sometimes have to wait for things to replicate to.
yes i know the history and excuse me for misnaming, but AD came out in 1998 IIRC whenever i hate-researched it. and it makes perfect sense for a business to do that but it is a terrible engineering platform because of that. what you said was my exact thought process the first time i encountered that tragedy, and that doesn't make it right or good. and now the enterprise businesses waste a lot of money in time spent paying engineers to work with the frakenstein.
This. Also try managing Gitlab permissions across a large org with lots of teams and lots of projects. Inheritance might seem like a good idea but it pollutes the hell out of everything once you're 3 levels deep in a org. I wrote some python scripts to generate a JSON dump of the whole org and from digging into it, some people have 30 different Access paths for some projects. Try locking that down without special tools.
"Roles inherit"? No idea what you're talking about.
> Lower levels inherit role permissions from higher levels...When you assign a role at a parent scope, those permissions are inherited to the child scopes
from the docs: https://learn.microsoft.com/en-us/azure/role-based-access-co...
I don't understand what's surprising about this.
>Roles fucking inherit??
Wdym?
i designed an extremely tightly scoped managed identity to do a job. my azure admin created the resources, and now that identity shows an inheritance chain that tracks all the way to that admin (aka a very privileged identity). which seems insane.
i tested the identity to make sure it couldn't do privilege escalation...still, wtf? it might be my own fault where i'm doing something wrong, but that shouldn't even be possible for somebody to create a managed identity that would inherit from other identities. i don't trust that it's ok and i shouldn't be spending time figuring out if it is, i expect tightly scoped identities to just work...
What inheritance chain? I'd say I'm quite proficient with Azure RBAC and I cannot understand what you're describing.
https://learn.microsoft.com/en-us/answers/questions/969822/h...
and
https://stackoverflow.com/questions/76618129/prevent-roles-f...
These don't clarify your situation, sorry. They're also referring to two distinct scenarios.
Especially regarding the SO question, I get the feeling that author is misunderstanding something.
Where exactly are you seeing what exactly that might imply some kind of inheritance chain?
i get the sense that you're not trying to help but instead argue about it. i already described as much as i want to detail: https://news.ycombinator.com/item?id=44445382
Okay. Then I'll lay it out: there is no inheritance at all. An identity does not inherit roles and it certainly does not inherit other identities. You are misinterpreting something you saw. However, without further details, a more targeted answer is not possible. I did not want to write a blanket statement like that because it is very condescending and hostile. Sorry about that.
You may have seen the identity's IAM page. It does not show roles assigned to the identity.
from the docs:
> Lower levels inherit role permissions from higher levels...When you assign a role at a parent scope, those permissions are inherited to the child scopes
https://learn.microsoft.com/en-us/azure/role-based-access-co...
so i guess this what you said is confidently wrong lmao like you couldn't even be more wrong:
> Then I'll lay it out: there is no inheritance at all. An identity does not inherit roles and it certainly does not inherit other identities.
i misspoke calling it "identity inheritance" and not "scope inheritance" tho my first comment said "role inheritance" but the fact that there is any sort of inheritance involved at all with my rbac roles is very poor design decision. and the fact that i can misunderstand this and spend hours of company time trying to understand it, and still failing....when this should be an intuitive, 101-level thing for cloud design. but nah i gotta spend time going through like ten different docs piecing together knowledge and pentest my own work and also argue with some guy on the internet who called himself adept at azure and doesn't know this either (which further proves my point!)
The so-called "lower levels" inherit role permissions (or role assignments, if you will), which is something else entirely. Furthermore I'd say this is both expected and necessary to effectively administer permissions in organizations. Assigning permissions (via roles or otherwise) on every single object is not feasible. Inheritance is required. It works similarly to NTFS ACLs.
What I wrote is, in fact, accurate. An identity cannot inherit a role. It is simply impossible. What would it inherit from? The identity does not actually exist where it appears in the control plane (ie. in a resource group). It exists in Entra ID (formerly Azure AD).
There is but one possibility for a newly created identity to actually have roles assignments: Automation via policy. Now that I think about it, there might be another: assigning roles to special groups like "Authenticated users".
ok so now it's a semantic debate. love that... i hope this knowledge that i shared is useful to you in the future, so you can avoid dumb ass RBAC inheritance footguns
I think this confusion is exactly the problem. “Roles inherit” is one of those Azure things that looks simple in docs but ends up creating hidden privilege sprawl in real environments. I’ve seen teams argue for hours about what gets inherited, what doesn’t, and who has access to what, just because a single assignment at the wrong scope can fan out across everything.
I'll take this opportunity to remind anyone on Azure that if you enable service endpoints on a subnet without applying service endpoint policies, anyone with the resourceid of an affected subnet can silently backdoor your network. Your NSGs do not matter for service endpoints.
Backdoora private network how? Or do you just mean that an NSG wont apply like you might have expected?
Azure complainers here clearly have not tried GCP lol.
This is crazy. Using HTTP methods to enforce API permissions? Only Microsoft could do something this lazy. No wonder their own developers are getting confused...
It’s a combination of scope, resource types/operations and action type (similar to HTTP method, but somewhat normalized). Not that different from most ACL based systems.
The main problem raised by the article is a governance failure.