For me personally, it would be much more useful if I could play with the policies interactively - issue requests with some tagging (a special access key maybe?) and see what permissions they need, what context they have and which of them are allowed/denied by the policies. And what if I edit this part, would it affect the recorded requests?
At the moment, it usually takes me several iterations to tune the policy.
So much this, I don't understand why cloud providers don't offer an easy way to view this sort of thing as really it should all be in the logging anyway.
The execution of rulesets needs to be performed synchronously and as fast as possible, since requests are blocked until they pass the permission checks; but it doesn't need any sort of replication since each request is validated independently.
Request logging can be performed asynchronously and has much more relaxed latency requirements, but data needs to be aggregated and replicated for durability.
The extremely different requirements pretty much guarantee that these will be two completely separate systems; by Conway's Law, this means two completely separate teams. In practice, logging is more aimed at business analytics and billing.
You're right that the information should be available, and there's no technical reason why it can't be made available, but there are technical reasons which influence the social reasons why it's not available.
It seems like AWS isn't good with cross cutting concerns. Eg instead of Cloudformation being part of a service during development, that they could even use during testing the service, every team creates a custom api and cf is an afterthought. It wouldn't surprise me if every service is also evaluating against iam policies independently as well.
That reminds me of the latter stages of Sun Microsystems, where it seemed like multiple teams were developing competing solutions for system management and patching. Seems a wasteful model and not one that is servicing customers.
Much of the services were built well before clod formation... Or cloud formation became popular... Or before everyone was willing to make the trade-off that features come later because they had to have cloud formation. Like any other best practice you invent along the way. I'll bet there's something about your 1/3/5/10/15 year old that isn't up to current snuff.
People forget, AWS is massive and taking care of edge case after edge case while being in a bullet point war with other cloud providers.
Even new features sometimes don’t get CloudFormation support for quite a while (sometimes longer than third-party support like Terraform). I keep wondering why they didn’t want it for their own integration testing.
AWS had the policy simulator for IAM policies but it hasn't been kept up to date wrt new features (like SCP)... Maybe they'll have something similar for this.
Cedar has a playground that supports much of what you're asking for or were you referring to IAM (AWS specific, and not model policies for your business).
It seems more akin to the IAM policy simulator to me. You need to know the specific action and context to play with the policy.
In the real case I don't know what context the actions carry that I may use for filtering, I don't know the action names and I may not even know the full list of API calls the tool I use wants to make.
> In the real case I don't know what context the actions carry that I may use for filtering
You do know all of this with Cedar as the service owner though. You know the attributes on the entities, you know the policies. Something is going over my head, because I don't think I understand the use case. Can you give a concrete example?
A real use case I ran into myself was when trying to grant a minimal set of permissions for creating EMR Notebooks. The AWS documentation for the PassRole permissions was incorrect and my team kept getting generic permission errors (cannot PassRole without saying what it can’t pass the role to) despite following it exactly, so we had to give broader permissions to get unblocked. Obviously they made some changes to the backend such that the documentation was out of date.
That's not Cedar or what Cedar solves. Cedar isn't replacing IAM, AWS's own policy DSL. It's a way for you to create your own IAM, and model it as you like. It has its own specification, and embedding Cedar into applications is a use case. I expect they're open sourcing it.
The hosted offering is AWS runs an evaluation engine at scale ensuring it's low latency so your own customers can access resources gated by your own entity and policy definitions.
I think we're getting wires crossed. I know that, and I know that Cedar doesn't solve this use case. I was jumping on with Krab's comment mentioning why something that works like a policy simulator isn't sufficient.
Probably we're looking at the problem from a different point of view.
Imagine I'm a new AWS customer that creates their account, starts an Elastic Beanstalk application and tries to automate deployment via CI. The access key will need some permissions to EB, EC2, S3, maybe RDS, ECR... The best thing I can do at the moment is to expect that an example policy is somewhere in the docs.
Yeah, what you are looking for is something like a "learning mode" for an IAM account where the key actually has wide-open permissions and the system records which permissions are used and generates a policy locked down to what you did while it was in "learning mode" then you can edit that policy and then turn the account into "locked mode" where permissions are limited to the created policy.
I've been in that position and more often than not I end up doing the "wrong" thing and give a key wider permissions than needed because trying to lock it down is so frustrating (especially if your CI process is long/expensive). Having to wait 5+ minutes for a CI to reach to the end and realized you missed 1 permissions, rinse and repeat 10+ times for "just one more permission" is frustrating/time consuming.
EDIT: Just saw this further down in the thread https://github.com/iann0036/iamlive (which you already replied to) which looks like it does pretty much what I'm looking for.
Cedar has nothing to do with AWS except that it's open sourced by AWS (I think?). It has nothing to do with IAM, an existing way to model policy specifically for AWS owned resources.
What you do once you model your application's authorization concerns in Cedar to make it so action:foo is exposed as usable on resource:bar is up to you, and your business. An anaylzer can be implemented on top of this for your domain and offer the functionality you're describing, but that seems out of scope for Cedar the modeling specification and evaluation engine to provide.
Imagine Cedar as a way for you, a SaaS provider, to add granular access policies like AWS for your own specific resources be it customers, rental cars, food orders, or advertising campaigns. I suspect the majority of use cases aren’t multi-tenant SaaS concerns but very complex authorization over resources internally across services in an organization. Does micro service A have access to update data on resource bar? It’s still hard to model and enforce those things as organizations grow, especially in a domain specific way.
> Cedar has nothing to do with AWS except that it's open sourced by AWS
It seems to me it's a tool made in AWS by some team close to AWS IAM. My original comment didn't relate that much to Cedar itself. Rather, I tried to express my long held frustration with AWS IAM which Cedar doesn't solve even though it must have costed a lot of effort.
Don't worry too much about it. I'm just a random Internet commenter talking about a topic that's not even mentioned in the original article but tangentially connected.
When we started working on Cerbos[1] the very first external bit of tooling we released was the Cerbos Playground[2] which does exactly what you say - allows you to see the requests and responses as they make changes to their policies, making it easier to test and refine their rules.
This is a great starting point to prototype and test whether a decoupled authorization system is right for your use case. Cerbos uses YAML rather than a custom DSL to try and address the fact that authorization requirements generally don't sit with developers, rather a product owner of some sorts who is going to want to be able to comprehend the logic behind the permissions model.
This goes in the right direction. Still it's not 100% reliable (e.g. S3 isn't logged by default to cloudtrail, probably due to volume). Also, not really interactive. I'm talking mostly about ergonomics. Obviously we can solve the issue and create the right policy - but it's not as easy as it could be. That in turn leads to some people skipping the process and staying with too powerful keys.
Data plane volumes are absurd and then you have to crunch it. I estimated this for my company. But you really wouldn't want to pay to do all that cloud trail processing yourself.
We have some buckets where the cloud trail storage with 1y retention is more than the bucket itself.
Hmm, what I had in mind was rather a tool that would generate a new access key (or some other way to correlate the requests) and record and show me in real time what permissions I need and let me play with that and simulate what API calls would fail with a policy that I'm just writing. Very low volume.
I think that predicates you know everything your libraries, pulled in containers, kube charts, etc are doing... I'd love it if I could just be told what I'm doing and see 'yeah that makes sense' and be alerted to changes.
This doesn't cut it. That tool helps if your role/user has a lot of policies that might interact between each other. But you already need to know the exact "actions" and context.
On the other hand, I have a tool that calls some AWS services that may in turn call other AWS services. Now if something fails because of IAM denial, I have to go through the logs to figure out what it needed, sometimes it's not even in the logs (S3). Then add it to the policy and repeat to see the next failed call.
I imagine being able to call real API calls, make them succeed and record what permissions it needed for each of those API calls. I don't need that as a permanent log, just as a development tool.
> You can simulate a policy with AWS IAM Policy Simulator
Is it reliable though? I have experienced many situations where a role has access to a policy and yet the policy simulator said that access is denied due to "organization policy" with no further ability to drill down to which policy it thinks denies access. And it did that when the role did have access to the resource and could work with that resource successfully. So I stopped trusting the simulator. I wonder if others too have experienced similar issues with the simulator.
Meh, looks like just another contrived configuration DSL to me. Doesn’t seem particularly innovative. Maybe needs some more complicated examples, but I bet 99% of the rules people will write look basically like the examples in the article.
Seems like a missed opportunity to invest in, say, OPA or something in the community to me. Probably was some dude’s L7 promo project in AWS.
> So a theoretician who had little experience actually using such solutions in real life?
These low-effort, borderline ad-hominem comments like yours make these comment threads a terrible reading experience. These comments add nothing to the discussion.
I disagree. when some tech seems to come out of nowhere, and disconnected from the general community practices, understanding the background of who made it can help understanding its blindspots.
also, the whole thing did not start with some kind of open white paper explaining the need, the rational for a new framework or language and comparing with alternatives, etc. which is often how oss projects start.
The comment added a very specific and valid criticism to the discussion: academics don't design for the real world. (In case I have to lead you down the path... the point being, the design will lack insight into how such a policy language might function in the real world, and thus not provide any significant advantage over existing policy languages, while simultaneously fragmenting said ecosystem)
This is yet another ad hominem which I frankly find very distasteful. Plenty of real world software that you see around has been designed by academics and are hugely successful in the real world.
Academics come in all varieties just like your engineers. There are good engineers and there are engineers with years of experience who design terrible software. There are academics who do not design for real world and there are academics who do.
Just throwing around the term "academic" in a loose manner offers no insight on the quality of the work. If there is any valid criticism it should be made on the work, not about the person behind it. That you come to defend ad hominem in more elaborate words goes to reaffirm my original point about why these comments make these threads a terrible reading experience! They often seem to show a shallow understanding of both the academia and the professional IT industry.
You realize the phrase ad hominem means a personal attack, right? None of us have made a personal attack. If anything, we are attacking the distinction between one institution and another.
We're pointing out that experience provides essential knowledge that a person who hasn't had experience lacks, a simple truth of life. Reading a book about performing surgery is much different than having actually performed the surgery. And someone who has worked in academia (aka "an academic") lacks experience in industry. An academic has not been actually applying the policies in a large organization for years, and thus cannot know or predict all the ways in which the practice of applying the policy can cause problems that do not present themselves in a non-industry setting.
Again, we are not attacking a person. We are specifically saying that any person who lacks experience is not going to make as good of a solution. This is not a controversial statement.
Ad hominem doesn’t mean personal attack actually. This is quite a frustrating misconception online.
Ad hominem applies to an argument wherein you try to discredit an argument by discrediting the person making the argument. I.E. “Person A is B therefore not C”. In this situation the argument that “This guy is an academic therefor his tool is unneeded” is absolutely an ad hominem.
If I said "Hitler was a racist, therefore he is not the right person to hire to run an Inclusion & Diversity initiative", that would be an ad hominem, and therefore a fallacy? No, because "what he is" directly impacts the subject in question. Claiming it was a fallacy due to ad hominem would be argument from fallacy, which is a fallacy. (A fallacy fallacy)
But this academic did design for the real world. He works for Amazon. This project is happening inside Amazon. How the heck can you be saying he wouldn't have insight into how such a policy language would function "in the real world", when he's literally designing this language at a "real world" company?
Amazon is a gigantic series of 2-pizza-teams and fiefdoms. They don't talk to each other much. Just because you "work at Amazon" does not mean you have ever serviced a single customer, or gleaned the experience of the tens of thousands of engineers working there (most of whom don't know the others exist).
But even so, let's assume this person has worked directly with customers, and knows how to design for the real world. Why might someone whose job is not being a practitioner, maybe not come up with the best design?
Take for example the product "Terraform", by HashiCorp. It has severe design flaws which anyone who has been forced to use it at scale will find immediately. But the person who invented it, and its subsequent developers, follow a "philosophy" that has nothing to do with working with it in the real world. It was not created by practitioners, for practitioners, but by idealists, for a corporation to ensnare hapless clients that have sadly adopted their freeware and now need to pay for add-on software to manage it. The end result? It sucks balls.
For an Amazon-centric example, take Terraform's competitor, CloudFormation. It's even more horrible. You write your configuration in a data serialization format, in verbose and clunky huge chunks, and (afaik) can't validate or test them without applying them in the cloud. There's no modules or extensions, and it doesn't really change or improve. It's like someone decided to only build the guts of a configuration management engine and told all the users to just figure out for themselves how to use it. You still need to build a whole 'nother software project just to interface with it in a sane way.
Back to the topic: Many other policy languages and tools already exist, many of them open-source. They could have simply adapted those existing solutions and extended them to include whatever novel, genius ideas they had that those other solutions didn't have. But they didn't. Why? I have no idea. But I'm betting it's not because they couldn't write patches for the other tool.
Does anyone actually like the policy language of OPA? Maybe I didn't invest enough time in learning, but I found it a terrible experience and the language to be counter intuitive.
This is an entry into the application AuthZ world. The space is in need of a general approach to get away from ad hoc solutions in every application or in the IDP. Cedar falls somewhere between OPA with its datalog (prolog) based search approach and a Zanzibar based approach. It’s not clear which direction will win out, but it is time that this problem got some attention.
Personally I prefer cuelang operating on JSON (aka IAM policy, kafka ACLs, IP blocklists, elasticsearch database config etc.) documents - cuelang-js is a wasm execution engine I can use with the cue binary across most apps/databases/kafka etc to have a unified policy engine.
The advantage here is that I can then simulate end-to-end policy what-ifs, and do build-time policy unit tests.
I can also handle business rules in a similar fashion for better visibility - how much of the business understands python/Go/Java/etc code?
>"Cedar falls somewhere between OPA with its datalog (prolog) based search approach and a Zanzibar based approach."
I understand the OPA from your description of it as a "datalog(prolog) based search approach" but you didn't characterize what the "Zanzibar based approach" is. Is there a similar short descriptive summary of its approach?
Zanzibar is an authorization system Google built and describes in a paper [1], which uses relationships to make authorization decisions (aka ReBAC): if there exists a path of such relationships between a resource's permission and, say, a user, then the user is considered to have that permission on the resource. This structural approach to permission checking allows for high levels of scaling and low latency on checks.
Disclaimer: I am the cofounder of AuthZed, where we are building an open source version of Zanzibar known as SpiceDB [2]
This has nice air of familiarity in relation to RDF (subject-predicate-object) and Datalog. And of course much more concise and readable than IAM JSON or YAML.
permit(
principal == ?principal,
action == Action::"download",
resource in ?resource
) when {
context.mfa == true
};
At this point realize that cloud formation is machine code, and cdk or terraform are the language you, a human, should use, like c/c++ but more like typescript.
What the machine needs is usually different from what you need. The machine solution sometimes comes first
A lot of people think CDK is a wrong turn. CF is just data. CDK generates CF without letting you do CF level transforms. It's an imperative wrapper to a inherently functional / declarative thing, and married to JavaScript to top it off. Generally wrapping a declarative, data based expression in a Turing complete API is a backwards direction - makes it less amenable to automated reasoning and risks intertwining incidental complexity of the GP programming environment like dependency churn and breakage in there.
Terraform is better but lots of shops are wary of relying on third party foundations.
I don't really get these arguemnts on why CDK is bad. I've got around 3k accounts, 300k aws resources, 1k devs, all working fine on CDK... I've never seen where functional / declarative change mattered. My issue with TFN is a half baked turing language that I fight a lot, and CFN is terrible for IFs or massifly repaeated.
I talked with the team building CDK... their market analysis was essentially: SysDEs love CFN or declarative. Developers hate repeating themselves and lack of abstractions. I generally agree with the latter. The lack of real modules, dependency management, compilers, etc are a put off for CFN and TFN for me. I'm loving CDK.
You could have both abstractions and DRY without mixing it in imperative library calls and opaque state. You could then write eg tools that apply changes robustly across all your stacks, inspect for security risks, check against custom schemas and policies, reusable things that compose better, etc.
I'm doing all of that actually... I don't see how "functional" and "declarative" is in any way helping... You're making statements without getting into the details.
For instance we run a linter for security issues and best practices during the cdk build... We have tools applying changes across our abstractions and against our non-abstractions.
In a declarative form the changes don't make it back into the declarative form unless you're pullling cfn state back into say git, or harder reversing it back into TFN state.
Think for example how you would robustly check that resources of certain types are labeled in a way conforming to a given schema, or that would rewrite the label values in your stacks to a newer format. Linting CDK code can't get you this.
It's possible of course that I don't know enough about CDK and these examples have CDK solutions.
Imperative and declarative are not hard requirements for this but they make the domain easier to reason about and they are a good fit to the CF model of configuration-as-data instead (vs CDK's configuration-as-imperative-code).
Cdk linters can 100% do this. They can operate at the various construct levels including level 1 eg generated cloud formation. At this point it's just making a linter/visitor that says "if type is taggable then it must have this tag" and bob's your uncle. The l1 stuff is generated from the cfn schema and so will have tags correctly.
I hope some of open solutions for policy management will prevail soon,like OPA, and all public cloud providers give support for it.
I did not expect from AWS to simply support OPA in this phase of problem/market fit for the complex system Auth. Still, not happy with yet another siloed solution which is proprietary to one cloud.
Looks like a decent improvement on readability of JSON IAM policy and the templating thing is cool.
I’m a bit unclear on why they needed a new DSL to be able to do “automated reasoning” on policy effects though. It doesn’t seem semantically that different from the existing policy docs we all know and love.
It's not a substitute/replacement for IAM, it's for their verified access product - basically IAM for your own applications. Nothing to do with IAM for your AWS account
I don't understand why there isn't a language spec on the official website: https://www.cedarpolicy.com It's nice that the AWS heroes have filled in some of the documentation holes on their sites, but we need the spec! Right now there is just a tutorial that reveals pieces of the spec and a simulator for a language that isn't defined anywhere.
I really think that ship has sailed. I mean recently there was an ASDF tool version manager that had nothing to do with ASDF the system definition facility. It is becoming more and more common to reuse names without any regards for tradition or history.
Sites should really stop using title case for news articles. Seeing the title on HN made me ask "what's an access control language cedar", even though it's "access control language Cedar".
At the moment, it usually takes me several iterations to tune the policy.