Hacker News Reader

Comment by krab | Hacker News Reader

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.

View on HN

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.

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.

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.

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).

https://www.cedarpolicy.com/en/playground

Interesting thing about the playground: the entire evaluator is apparently in a WebAssembly binary located at https://www.cedarpolicy.com/waterford_wasm_bg.wasm

It gives me a little hope on the direction and ability to embed Cedar in non-AWS contexts.

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.

AWS knows (could record) all of the above for me.

> 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?

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.

Again, something is going over my head.

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.

All good. Just making sure I wasn’t missing something myself.

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.

(Disclaimer: I work for Cerbos[1])

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.

[1] https://cerbos.dev [2] https://play.cerbos.dev

The book AWS Cookbook section 1.2 is on 'Generating a Least Privilege IAM Policy Based on Access Patterns'.

[1] https://www.oreilly.com/library/view/aws-cookbook/9781492092...

[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...

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.

You can simulate a policy with AWS IAM Policy Simulator

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 do this with Localstack, however it's gated behind their pro service.

https://docs.localstack.cloud/user-guide/aws/iam/#explainabl...

All of the sdks support client side monitoring (CSM), so these sort of tools can be built client side. https://boto3.amazonaws.com/v1/documentation/api/1.10.46/gui...

afaics the only challenge is mapping some of the apis to iam as its only 85% 1:1

There's also tools for helping with iam like (generator, and linter)

https://github.com/salesforce/policy_sentry

https://github.com/duo-labs/parliament

> mapping some of the apis to iam as its only 85% 1:1

Yeah. Try to create an Elastic beanstalk app with only EB permissions.

actually Ian (aws hero) has a tool that does exactly this

https://github.com/iann0036/iamlive

Oh, thanks a lot!

> 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.

Reply on news.ycombinator.com