January 1, 2024
I’m Dr. Rohit Khare, a computer scientist trying to make Identity & Access Management (IAM) easier and more effective. As a Google product manager, I launched IAM with “only”a few hundred controls. Now there are almost 50,000 entries on Permissions.cloud across Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure!
With the tools we have today, it’s no surprise customers can’t configure such complicated controls correctly — yet Cloud providers rely on a “shared responsibility” model to blame breaches on developers. I played my part in this stubborn status quo, so I’d like to atone for my sins, so to speak.
I’ve led product development at cybersecurity startups commercializing open-source approaches to automating governance, risk, and compliance for Cloud IAM, at Stacklet.io and Noq.dev. I’m excited about new efforts emerging from the Authorization (AuthZ) community, so I’ve started volunteering to help curate news clippings and convene a conference in 2024.
Even though I don't have any specific solutions to start from, I’m going to use DecentIAM.com to understand the problem space, track new technologies, and learn from new leaders. I also hope it’s helpful to you, dear reader, since I’d like to learn from your experiences, too!
January 2, 2024
I’ve grown so old that I had to do the math to confirm that I was still a teenager when I sold my first software package. Confidante (not this one from UW) was an encryption plug-in for NeXTMail, for a domestic security agency. I became an international arms dealer, as elite a cypherpunk as I could dream of, back in those days of ITAR export controls for RSA BSAFE floppy discs!
I was almost as lucky to learn about crypto as an undergrad as I was to focus my career on the World Wide Web so early I could still trade tips on hacking together a WYSIWYG editor for HTML with the original inventors at CERN. Eventually, my first IETF Standard was another minor milestone at the intersection of the Web and Security (h/t to Scott Lawrence!).
The lasting impact of RFC 2817 was creating a registry of tokens for ways to upgrade an basic HTTP connection to speak alternative protocols, such as WebSockets today. That, in turn, was necessary so TLS could advance up the Standards track itself.
I was too embarassed to publish this entry without encryption, so I finally dug into what it would take to turn HTTPS on for my own Web server. Boy, am I glad I waited — I've never dreamed how easy EFF’s CertBot would make it to deploy Let's Encrypt certificates on my ancient, jury-rigged Apache setup. Kudos to everyone involved for an excellent user experience!
What a long, strange trip from helping organize catering and sponsoring the first IIWs to buying my own ticket as an individual civillian nineteen years later! I just registetered for the Internet Identity Workshop and recommend it to anyone else who can make it to Mountain View from April 16-18, 2024 by the early-bird deadline next week
This time around, I'm excited about the rise of authorizaiton on the aganda, arguably a return to the original emphasis on OAuth as “Open AuthZ” after dacades of convening the right community to have nailed down Internet-scale AuthN with OIDC and advocacy from the sovereign identity folks
Forced to brainstorm on-the-spot, here were a few un-conference topics I thought up before my shopping-cart expired:
January 10, 2024
It’s crazy we can’t test changes to Cloud security policies. We wouldn’t change code in production without version controlled releases, automated regression testing, and gradual rollouts — yet none of those are common practices in IAM today.
Infrastructure-as-Code (IaC) enabled the revolution in DevOps affairs by replacing interactive Cloud configurations GUI clicks and API calls with text files that could be checked in and reviewed just like ordinary code. From Chef to Helm charts, all sorts of new domain-specific languages have emerged for describing “what” to deploy, instead of “how” to deploy it.
Yet when it comes to creating a new identity for an intern, making them a member of the team, or allowing them access, very few of those changes are captured in a file format that’s easy to analyze, approve, audit, or apply.
Putting all of those IAMOps under Git version control was why we invented IAMbic.org at Noq: “IAM, but in code.” Now, Terraform, CDK, and many other approaches all include constructs that represent IAM roles, policies, and users, so there’s all sorts of appropriate arguments about what features make a new language necessary (or not). IAMbic can also define directory entries, to control group memberships, for example.
Administrators benefit from all the advantages that accrue from applying all changes -as-code:
Since testing is the beginning of enlightenment in engineering, it seems hard for me to imagine our industry ignoring first-class support for something like Git before making changes to Cloud configurations for IAMOps. Or, for that matter, for FinOps (accounting, budgets, quotas, etc), PrivacyOps (geographic jurisdictions, support investigations, derived data leaks, etc), or other Governance policies (supply chains, build horizons, launch reviews, etc).
Only once everything’s in Git can we claim to create a true “digital twin” for testing Cloud configurations. Only once we can replicate and simulate the impact in advance can begin to tackle two other pillars of a Decent IAM: automated reasoning to enforce higher-level policies written in natural language.
Footnote:To be sure, Cloud providers typically store the past few revisions to an IAM roles or policy and include APIs to roll them back, as well as audit logs of those changes. However, those identifiers aren’t aligned to revisions from the customer’s code repositories, nor are individual changes attributable across transactional changes as they might be if the primary abstraction to the control plane were “just Git.”
January 11, 2024
It’s crazy that policies aren’t in plain English, especially with all the hype around generative AI! After all, the stakeholders that set policies — from legal officers to line managers to government regulators and accounting auditors — already document their requirements and rationales in natural language. Sure, it might not sound natural, written in legalese laden with industry-specific jargon, but that’s still far from JSON. And even if there were a Google Translate for compiling plain text back into code, would a collaboration platform for policymakers work more like Wikipedia than GitHub or Jira?
The original sin of Policy-as-Code (PaC) is that coders don’t
care about (most) policies. “Setting budgets to cap intra-day
exposure to trading with counter-parties” isn’t as easy to enforce
as “only admins can issue refunds.” Whether the notion of
administrator-ness were implemented in role-based (RBAC),
attribute-based (ABAC), relationship-based (ReBAC), or any other
ACL, it’s still a straightforward analogy to guard the code that
issues refunds with an if-statement that checks for
an issueRefund permission.
Coders that care about avoiding crashes can also appreciate boolean formulas for blaming callers. The vaunted “Shared Responsibility” model of Cloud security that redirects most of the real responsibility onto Cloud customers also appears to recur within IT, between separate services and teams. Adopting a modern authorization approach by documenting your own users, resources, and permissions (“names, nouns, and verbs”) is easiest when the nouns are exactly what you defined in your database schema, the verbs are exactly the methods you defined in your API, and the complexity of configuring it correctly is left as an exercise for the operators.
The promise of Policy-as-Code is that extracting all the business
logic for making risky decisions from the application logic and
placing it on a separate control plane would allow all the
stakeholders to review and revise the company’s policies, without
having to individually adapt all their apps. When that business
logic gets reduced to “I can has Cheezburger,” that’s pretty
simple code to check for getCheezburger
permission. What about the real-world, when “Any admin can issue
refunds” becomes “Any admin can issue refunds, except to
themselves, other employees, or family members; and then only up
to $XXX and less than YY% of daily transactions; and never for any
SKUs marked as non-refundable by law or discontinued; and never in
a different currency than the original form of payment …”?
Look, I’ll admit that’s a laughable example of a natural language policy. Still, if I had a nickel for every cybersecurity startup sales pitch slide deck where one side showed the goals of a policy and the other half had some cryptic code in their domain-specific language that didn’t really reflect that in reality… then I might have enough nickels to a buy a donut, one with a hole big enough to fit all the loopholes in that logic.
What I wish we could say was, “Interns have no business looking at customer’s data in production” and turning that into limitations on which databases, buckets, folders, and functions interns are allowed to access. When, inevitably, an intern gets assigned to the Customer Success team trying to write a tool to recover lost records, there should be an equally clear, plain-English policy for exceptions: to request privileged access, to justify which customers have consented, to grant a (temporary) escalation, and to archive and audit all of their actions afterwards.
Can we get there from here using any of today’s popular proposals for policy programming languages? Would it be just another “low-code” success story for turning prompts into JSON-formatted IAM changes? Could we use ChatGPT as a co-pilot for writing with existing PaC languages? Or would it be even more unreasonable to turn over responsibility for cybersecurity to error-prone, hallucination-prone, and jailbreak-prone AIs?
I’m optimistic that an LLM might understand “intern” well enough to identify the ‘summer-2024@’ group in a directory system; and probably able to map “production” to the “env=prod” tag found on Cloud resources — but I’m not at all confident any AI could map out a SaaS code base well enough to identify all the pathways “customer data” flows through. It will probably require a dialog with all those folks-who-don’t-code to write up what kinds of private information their app processes, where it’s located, and when various derived data products, like analytics about app usage, are de-identified enough to not constitute “customer data” anymore.
Today, though? Even restricted to asking for assistance with IAM permissions defined before an LLM’s training cutoff date, a textual approach appears insufficient to connect the dots between all the attack paths that we are still uncovering in misconfigurations of IAM. I strongly suspect that LLMs will have to be coupled with automated reasoning, the third pillar of my approach to building a more-decent IAM… so stay tuned to this blog!
January 31, 2024
Another idiosyncratic approach I take to AuthZ is imagining quotas and budgets as additional aspects of authorization. Instead of treating them as entirely orthogonal operations that are invoked after checking permissions to further filter, delay, or reject proposed actions, I think the same policymakers and stakeholders that want to protect Interns from exposure to private end-user information in production also want to protect Interns from the consequences of buggy actions that could run up huge compute bills or send out spam emails. Instead, I’d claim that instead of only issuing black-and-white, Yes-or-No, Grant-or-Deny decisions, any DecentIAM service ought to make elastic decisions depending on the resources and capacity available.
Here’s how a fourth factor might fit in context with the other three essential elements of any DecentIAM system, in my opinion:
Automated reasoning must show how this actor has permission to take this action on this resource, at this time, under these current conditions: Why is this possible?
Natural language policy translations must be accurate enough to also clearly summarize the rationale: Why will this be wise?
Version-controlled, human-readable, and complete configurations of IAM with auditable change logs must explain how policies were approved: Why was this allowed?
Real-time evaluation of costs and available capacity against policies limiting rates, budgets, locations, and other quotas make it possible to determine, in advance, whether sufficient resources are available to take an action: Is this affordable?
Bringing economics into the fold might appear to add more complexity than it’s worth. But I’m optimistic a unified theory (and policy language) for authorization may make DecentIAM more attractive to developers and more effective for business leaders.
From an implementation perspective, inside the hyperscale Cloud providers, these are entirely different control planes, of course! Quotas are enforced by the service mesh routing layers that rate-limit, redirect, fill, and draining in-flight requests between computing clusters operating at varying code release levels. And Billing is another service entirely, often post-processed to avoid impairing availability and sometimes unable to compute total job costs until the work’s almost completed, making any budget caps softer and less tied to real-time clearing or credit risk than one might imagine.
August 6, 2024
I had the pleasure of presenting a talk summarizing everything I've learned from half a year of helping edit our weekly AuthZ newsletter for, of all organizations, the Internal Revenue Service (IRS)!
Contact: rkhare@gmail.com or LinkedIn