[HN Gopher] Iamlive - Generate an IAM policy from AWS client-sid...
___________________________________________________________________
Iamlive - Generate an IAM policy from AWS client-side monitoring
Author : aynawn
Score : 74 points
Date : 2021-02-06 12:28 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| benkoller wrote:
| This is a great approach to determine permission especially for
| service accounts - thanks for giving me another tool for my
| toolchain.
| heybrandons wrote:
| thank you for sharing this!
| joshuanapoli wrote:
| Iamlive sounds useful for someone who has something running with
| wide open permissions and wants to get started with narrowing
| down the permissions. It wastes a lot of time to discover
| necessary permissions one-by-one through permission-denied
| errors.
|
| Tag-based policies (attribute based access control) really
| simplifies IAM policy management. These are more reusable, so
| there is permission discovery isn't needed as often.
| flurie wrote:
| ABAC is ideally much more than just scoping small sets of
| policy to tags. I think the problem of trying to shoehorn ABAC
| into AWS's IAM system, even with something implementing proper
| ABAC on top of it, is that you run the risk of hitting limits
| on role policy attachments (hard limit of 20!). There is
| probably a way to juggle user function across different roles,
| though then there's a risk of exhausting roles or still not
| being able to shoehorn a minimally viable policy for some
| function based on fine-grained attributes.
| gingerlime wrote:
| could you expand on that? my familiarity is very limited with
| IAM (as fun as getting teeth pulled), and this sounds
| interesting.
| uzakov wrote:
| I can try to explain it in a simplified fashion: When
| provisioning entities (EC2 instances for example) you go
| through certain settings (for this example I am talking about
| a manual provisioning through the UI, not IaC, CLI etc) and
| one of the things you can do is give EC2 instance a tag.
| There are a number of reasons to do tagging, to name a few:
| To make it easier to find a particular instance, cost
| optimisation, see who owns it. After this you write a policy
| that says what user/entity can do. This policy can take
| advantage of the tag, to say: "Only user, who has a tag XYZ
| can stop this EC2 instance that has tag XYZ" Let me know if
| that does not make sense and I can go a level simpler
| coredog64 wrote:
| In theory, ABAC solves a lot of problems. In practice, there's
| no mandate for AWS product teams to support ABAC in a
| consistent fashion.
|
| Assuming it doesn't cause networking issues, IMO the best
| approach is to finely scope AWS accounts. They're free, and
| Amazon includes some reasonable tools for working with them.
| The major downside is the double charge on Transit Gateway
| traffic.
| bndw wrote:
| Will this work with Terraform? I'd love to find a way to generate
| an IAM policy based on Terraform manifests.
| orf wrote:
| I think IAM is really, really cool. I've always wondered: is IAM
| a service under the hood? Surely not - the volume of requests
| would be insane and the single point of failure pretty risky.
|
| So is it a spec with some kind of shared data plane to retrieve
| policies? If so how would they be evaluated consistently across
| different languages? Producing a shared library that does this in
| all contexts/languages sounds improbable. But then the policies
| are clearly compiled to some kind of bytecode, so a common
| implementation would make sense. But then again it is something
| that would definitely benefit from centralisation.
| yandie wrote:
| ex-AWS here. IAM is definitely a service! It's super powerful
| underneath the hood.
|
| However as a caller, you need multiple levels of caching
| underneath the hood (all built by IAM team). That's part of the
| reasons why you can't use IAM as an external service.
|
| IAM is also eventual consistency - that's why if you modify the
| policy doc it takes seconds to reflect in your service calls :)
| (sometimes even minutes). IAM outages can and will take down
| multiple AWS services.
|
| > If so how would they be evaluated consistently across
| different languages?
|
| Internally everything is JVM AFAIK :). If you go out of the JVM
| world in AWS you'll have to deal with this problem yourself,
| which can be painful.
| orf wrote:
| Thanks! That's super interesting. There's something really
| cool about building something as flexible and (presumably)
| fast as IAM.
|
| The caching layer must also be quite complex! But thanks for
| settling this for me.
| jcims wrote:
| I'd never heard of the Client Side Monitoring tooling that this
| appears to be using. Is anyone in here using it to any effect?
| cddotdotslash wrote:
| It's a "hidden" (in that it's not documented very well or
| advertised much by AWS) feature of the AWS SDKs. I think it was
| likely added for debugging purposes originally, but security
| tools have started to hook into it as a more local and compete
| version of the kinds of logs you'd see in CloudTrail.
|
| I've used it mostly for debugging and temporary monitoring of
| service calls.
|
| https://summitroute.com/blog/2020/05/25/client_side_monitori...
| tyingq wrote:
| I'm curious if the tooling could be made to work with a
| "default deny" policy, that is, is there enough info to
| generate the IAM policies when you get "permission denied"?
| johnnyAghands wrote:
| Wow so just yesterday I was trying to figure out more restricted
| policy set for an instance someone else created. This is great!!
| wincy wrote:
| I can't really judge the usefulness of this tool as I'm not that
| familiar with IAM, but I'd be wary of using this in a work
| situation because I would be really worried I'd accidentally
| search for "imlive", which is an adult cam site.
|
| Maybe I'm just being paranoid but it feels like if I
| unintentionally named my super useful and totally innocuous
| project "poorNHub", I'd want someone to point out how that might
| cause problems down the line for adoption.
| krab wrote:
| Fair point. But what would happen? Even if you accidentally
| opened that site, most probably nobody would have noticed. Or
| it would have been just a short awkward moment.
| random5634 wrote:
| Not in me too time.
|
| One good solution - turn on adult content blocking on
| firewall. Saved me once or twice if you typo, missearch etc.
| I'm usually like huh when it blocks? Then oh...
| f430 wrote:
| would it be possible for this to be hooked up to existing
| serverless frameworks? it would be great if something could scan
| the code and generate an IAM policy.
| zackmorris wrote:
| I've dabbled in dev ops in recent months and found that setting
| up AWS services is relatively straightforward. Although for
| anyone reading this, do yourself a favor right now and learn to
| automate the manual steps with something like Terraform or you'll
| most likely never get anywhere in any reasonable amount of time.
|
| I found IAM to be an anti-pattern. I grew up on the Mac in a
| sandboxed, single-user environment with no console. And I've
| always approached roles and permissions as something that should
| be backend-only. So for web hosting, it should be host-only and
| not exposed to the customer.
|
| So to me, a service like VPC should have created a sandbox that
| handles IAM internally. It should have provided the customer with
| all AWS services exposed (even oddballs like SES) in that sandbox
| only (not accessible from outside) similarly to how managed
| hosting worked a decade ago.
|
| Basically IAM feels like hand waving to me. Few insights can be
| gleaned by looking at the roles and permissions by eye. So I
| would argue that most AIM setups as they stand now are probably
| insecure.
|
| The way it should probably work is, the customer would set up a
| series of access tests that run similarly to Postman and exercise
| the infrastructure the way that something like Dredd does with
| Swagger or API Blueprint. They would "prove" the permissions
| ruleset by traversing the AWS infrastructure, telling you which
| ones to add/remove.
|
| So conceptually, I think that the article or something similar is
| how IAM should have worked in the first place. Thought I'd use
| this opportunity to ask any dev ops people about this, because it
| feels like I'm missing something fundamental here. Any approaches
| to formally proving that IAM roles and permissions are secure
| would be greatly appreciated!
| rasguanabana wrote:
| On one hand you have people setting wildcards in IAM policies
| for development phase (and forgetting to close them down
| afterwards). It's hard to figure out permissions beforehand -
| this would help in these cases, but still taking IAM setup
| deduced from your traffic does not mean this setup is secure.
|
| On the other hand you have complex architectures and no real
| overlap in their authorization patterns. It's impossible to
| automate creation of secure "sandbox" setup for your specific
| use case.
|
| You can't really delegate security of your architecture to a
| single service - you need to address it yourself. Security can
| be implemented only _in_ the service, not _as_ a service.
| zackmorris wrote:
| Ya I've done that hah. I think an ok plan might be to set up
| infrastructure with open IAM rules and write all of the
| backend and frontend acceptance tests for an app. Then close
| all IAM rules and open them one by one until all of the tests
| pass again.
|
| Maybe AWS could provide a way to track access attempts and
| then have an interface for the user to grant them one by one.
| I understand that this might be challenging to design, but I
| view these sorts of challenges as the "real work" of computer
| science, otherwise there's just nothing there.
|
| I encounter that a lot when I have a preconceived notion of
| the heart of a strategy (including edge cases), only to find
| that it wasn't addressed, and in fact wasn't even mentioned.
|
| Yes these things are hard, but Amazon has billions and
| billions of dollars.
| musingsole wrote:
| This is a thriving service market at the moment. DivvyCloud
| is an example:
| https://aws.amazon.com/solutionspace/financial-
| services/solu...
| uzakov wrote:
| Hey! So to touch on a couple of points: Scott Piper is probably
| one of the most known AWS sec experts, check out his websites.
| https://summitroute.com/blog/
|
| "Any approaches to formally proving that IAM roles and
| permissions are secure would be greatly appreciated! " Are you
| looking for a way to see that you have set up your policies
| correctly?
| zackmorris wrote:
| Ya after writing it, I think what's going on is that I do
| everything declaratively now. So it's great that AWS lets us
| create the AWS policy files rather than making us manage
| permissions through code.
|
| But I want to see the infrastructure as a big spreadsheet,
| turn on a policy, and see the accessible services highlight.
| basically I need something like an acceptance/integration
| test that proves that my permissions work like I think they
| do.
|
| Without something formal like that, I can't help but feel
| that IAM is risky to rely on alone. To the point that, I
| would be wary of using it, and even view it as more of a
| liability than a useful tool. This is really a general
| conceptual issue with the abstraction of roles/permissions
| from a computer science perspective. My gut feeling is
| probably that the general authentication-based logins of the
| open internet and circles of trust are better mechanisms for
| securing services. That said, I do really appreciate that we
| can reference security group ids in new security group rules.
| Once I started chaining the references like that, and having
| subnet rules in a central place, things worked more smoothly.
|
| I would never use roles/permissions for new development
| though is what I'm trying to say (whether for web development
| or web hosting). I don't think it makes sense to screen
| access by which network was used, or the source IP of the
| user trying to gain access. These are somewhat antiquated
| notions that make sense for sysadmins, but I don't think they
| make sense for the vast majority of use cases that web
| developers encounter. We could just use the open web's
| CLIENT_ID=abc, CLIENT_SECRET=xyz pattern for all AWS
| services. But maybe there's some advantage with roles and
| permissions that I'm not seeing.
|
| Sorry I come off as Negative Nancy, but this issue really
| concerns me, and I don't see much talk about it on sites like
| Stack Overflow.
| Terretta wrote:
| Pull this thread...
|
| _Zelkova uses automated reasoning to analyze policies and
| the future consequences of policies. This includes AWS
| Identity and Access Management (IAM) policies, Amazon
| Simple Storage Service (S3) policies, and other resource
| policies. These policies dictate who can (or can't) do what
| to which resources. Because Zelkova uses automated
| reasoning, you no longer need to think about what questions
| you need to ask about your policies. Using fancy math, as
| mentioned above, Zelkova will automatically derive the
| questions and answers you need to be asking about your
| policies, improving confidence in your security
| configuration(s)._
|
| https://aws.amazon.com/blogs/security/protect-sensitive-
| data...
|
| Maybe start at Provable Security:
| https://aws.amazon.com/security/provable-security/
| uzakov wrote:
| Dont worry, I didn't feel that you were a "negative nancy"
| :)
|
| > "But I want to see the infrastructure as a big
| spreadsheet, turn on a policy, and see the accessible
| services highlight. basically I need something like an
| acceptance/integration test that proves that my permissions
| work like I think they do."
|
| This problem can be solved by having your infrastructure
| etc as Terraform templates, and writing unit tests for
| those. Additionally you can use 3rd party solutions,
| depending on what you mean by "see the accessible services
| highlight"
|
| > " I don't think it makes sense to screen access by which
| network was used, or the source IP of the user trying to
| gain access."
|
| I would say this is additional thing you would do, but not
| the only.
|
| > "But maybe there's some advantage with roles and
| permissions that I'm not seeing."
|
| Let me/us know and maybe either me or someone else can help
| you. Hopefully my message didnt come as condescending. PS I
| dont work for AWS
| DSingularity wrote:
| Google cloud got IAM right. I know of no approach to AWS IAM
| other than start with granting all perms and then begin to reduce
| privilege until things break.
|
| AWS is untenable.
| musingsole wrote:
| I've always worked in the AWS world and have only dabbled in
| google cloud, but hot rocks on a sunday evening if this clear
| page isn't refreshing coming from AWS:
| https://cloud.google.com/iam/docs/permissions-reference
| arduinomancer wrote:
| I know there's other projects with the goal to generate policies
| from the live behaviour of apps but I've always wondered how
| practical that actually is.
|
| It seems difficult to make sure you actually exercise every path
| of your app so that it makes every API call.
|
| It makes me wonder if live monitoring or static analysis is the
| better approach.
| Dunedan wrote:
| I have the need to run client-side monitoring for AWS Lambda
| functions, but haven't managed to figure out yet what's the
| easiest option to do so.
|
| While I could point AWS_CSM_HOST to some external IP-address, the
| lack of encryption and authentication makes that pretty
| nonviable. Alternatively I could put the AWS Lambda functions
| into VPC, but I'd prefer a less invasive change to the AWS Lambda
| functions.
|
| Does somebody here have a better solution for that?
| ttul wrote:
| This is a analogous to the creation of a chroot jail (or, in more
| modern times a container) by observing a running app via pstrace
| and the like and noting which files it accesses. It's a really
| powerful technique that can save a great deal of time for the
| programmer while ensuring the attack surface is as small as it
| can possibly be.
|
| Back in the dark ages, I wrote a tool to create chroot jails in
| OpenBSD so as to minimize the size of a tar ball that would need
| to be distributed to run an app in an embedded system. Those
| days, flash storage was tiny and expensive, so not only was the
| jail technique more secure, it also saved money.
___________________________________________________________________
(page generated 2021-02-06 23:02 UTC)