[HN Gopher] Azure API vulnerability and roles misconfiguration c...
___________________________________________________________________
Azure API vulnerability and roles misconfiguration compromise
corporate networks
Author : ArielSimon
Score : 94 points
Date : 2025-07-02 13:59 UTC (9 hours ago)
(HTM) web link (www.token.security)
(TXT) w3m dump (www.token.security)
| rohan_ wrote:
| Anecdotally - working with Azure has been hell on earth for me.
| Insanely unintuitive and buggy interface. Many cryptic errors
| preventing me from doing anything.
| comrade1234 wrote:
| 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.
| patmorgan23 wrote:
| Is AWS any better? (Genuine question)
| felixgallo wrote:
| (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.
| arccy wrote:
| 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
| programmertote wrote:
| 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.
| everfrustrated wrote:
| AWS IAM is very very well designed. They clearly have some
| sort of internal security & architecture review process
| that works.
| arccy wrote:
| 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
| mdaniel wrote:
| 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
| coredog64 wrote:
| 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)
| belter wrote:
| 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.
| Anon1096 wrote:
| 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).
| lifty wrote:
| 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.
| p_ing wrote:
| How does this not apply to - insert any product - in an
| enterprise space? With rare exceptions, users don't decide
| which software they use.
| lifty wrote:
| You're right. It's the embodiment of enterprise software
| sales. But some how AWS and GCP do it a bit better.
| everfrustrated wrote:
| 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".
| dminvs wrote:
| 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)
| aktuel wrote:
| That probably explains why all enterprise software sucks.
| motorest wrote:
| > 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.
| p_ing wrote:
| 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.
| motorest wrote:
| > 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.
| p_ing wrote:
| 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.
| koakuma-chan wrote:
| Yeah that, and in Azure OpenAI you have to create a separate
| deployment for each model you want to use.
| tstrimple wrote:
| > 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.
| everfrustrated wrote:
| >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.
| p_ing wrote:
| The footnote points out that those are minimum limits.
|
| https://learn.microsoft.com/en-us/azure/container-
| registry/c...
| tstrimple wrote:
| As noted, those are minimum limits. If there's a clown
| show, it's you who is hosting it.
| motorest wrote:
| > 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.
| motorest wrote:
| > 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.
| tstrimple wrote:
| 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.
| motorest wrote:
| > 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?
| mawax wrote:
| 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.
| snupples wrote:
| Which is exactly the opposite of how to effectively manage
| applications, code, and change at any scale beyond a home
| project.
| jiggawatts wrote:
| 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.
| mawax wrote:
| 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.
| motorest wrote:
| > 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.
| p_ing wrote:
| > 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/...
| motorest wrote:
| > 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?
| p_ing wrote:
| 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.
| motorest wrote:
| > 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.
| mawax wrote:
| 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.
| motorest wrote:
| > 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.
| p_ing wrote:
| 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.
| motorest wrote:
| > 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.
| p_ing wrote:
| 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!
| SvenL wrote:
| 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...
| p_ing wrote:
| 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.
| amysho144 wrote:
| 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...
| whoamii wrote:
| 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.
| idosh9 wrote:
| 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.
| greenie_beans wrote:
| 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?
| high_na_euv wrote:
| >Roles fucking inherit??
|
| Wdym?
| greenie_beans wrote:
| 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...
| fuzzy2 wrote:
| What inheritance chain? I'd say I'm quite proficient with
| Azure RBAC and I cannot understand what you're describing.
| greenie_beans wrote:
| https://learn.microsoft.com/en-
| us/answers/questions/969822/h...
|
| and
|
| https://stackoverflow.com/questions/76618129/prevent-
| roles-f...
| fuzzy2 wrote:
| 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?
| greenie_beans wrote:
| 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
| fuzzy2 wrote:
| 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.
| greenie_beans wrote:
| 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!)
| fuzzy2 wrote:
| 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".
| greenie_beans wrote:
| 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
| motorest wrote:
| > 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?
| greenie_beans wrote:
| 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.
| patmorgan23 wrote:
| 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.
| raffraffraff wrote:
| 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.
| bongodongobob wrote:
| "Roles inherit"? No idea what you're talking about.
| greenie_beans wrote:
| > 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...
| yolo007 wrote:
| Azure complainers here clearly have not tried GCP lol.
| sofixa wrote:
| 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.
| gwynforthewyn wrote:
| 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.
| 0cf8612b2e1e wrote:
| ... it was written by an enthusiastic junior dev and released
| with little review
|
| This feels true of so many Windows applications. Super rough
| POC that then gets released and locked into stone forever.
| jiggawatts wrote:
| 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.
| jlarocco wrote:
| > 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.
| filleokus wrote:
| > 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
| CamouflagedKiwi wrote:
| 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.
| ptx wrote:
| 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.
| c45y wrote:
| They bundle versioned API schemas....looooots of them.
|
| It would be a garbage fire in any language
| CamouflagedKiwi wrote:
| 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.
| jlarocco wrote:
| 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.
| coredog64 wrote:
| 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.
| magicalhippo wrote:
| > 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.
___________________________________________________________________
(page generated 2025-07-02 23:01 UTC)