I may have cussed at my screen a bit when I read this DarkReading article earlier.
Look, any standards-based implementation of Kerberos is subject to intentional misuse of Kerberos, which is what pass-the-ticket and similar Kerberos-centric attacks rely on. It’s like saying SAML or OAuth is bad, just because someone can compromise your federation infrastructure and mint tokens. It’s like saying there’s something wrong with your house, because someone can make a duplicate of your front door key. It’s not exactly a hot take.
Neither is the implication that harvesting access keys from an Azure storage account is a security oversight. There’s a security oversight, alright…but it has nothing to do with Azure storage accounts. If someone unauthorized has access to your cloud management plane, you have already lost. The fact they can run a command to extract access keys is a consequence, not a cause; the vulnerability is inadequate access control design. Fix that instead, and solve this + about 100 other potential attack vectors in one go.
These kinds of management plane attacks are something Microsoft address in great detail in the Azure Landing Zones reference architecture, for just this reason. A Domain Controller might have a robust internal Active Directory access control model, but from a cloud perspective, it is just a collection of resources, no different than any other: some compute, disks, and a network interface. The management plane flattens the internal Active Directory access control mechanism because if you can execute code against the VM (using built-in Cloud Shell, for example), you are effectively a Domain Admin (or will be soon). That’s not an inherent failure in traditional AD, that’s a failure of your privileged access control model in Azure.
That’s why we spend so much time in ALZ talking about the Management Group/Subscription hierarchy; you can inadvertently allow access to sensitive resources because of the downward propagation of privileges, or by leveraging Azure Policy. There are clear architectural patterns for isolating any and all resources in Azure, including the isolation of sensitive workloads such as storage accounts, key vaults, and sensitive compute resources like Domain Controllers. And the same rules apply for using Azure-centric Kerberos resources, such as those in Azure AD, or in the Azure AD Domain Services PaaS offering.
If you’re using Kerberos, you get the good with the bad. This might be controversial, but…if you’re using Kerberos in cloud for anything other than a temporary migration stop-gap to a more modern way of authenticating and authorizing access, I would respectfully suggest that there are other (and better) ways, for almost every use case.