jon918

Great point on doing things through PRs not clickops. As your practices mature, the need for approvals can shift from the care and feeding of your infrastructure to managing risk. Even with IaC in place, having controls around who can access customer data, internal admin panels, and other resources with a high blast radius is critical. We built Sym to serve as a flexible approvals layer that can adapt along with you as your stack evolves. There will always be new services and teams to incorporate, and we want to ensure you can always easily add in guardrails that give you sufficient control and visibility into what teams are up to without introducing unneeded bottlenecks.

Thanks so much for the feedback!

> I was thinking of launching an access management project myself. Most access management systems are focused around SSO, and this - due to the SSO tax - is not for every application in a small organization.

Great point. SSO integrations also don’t necessarily provide the level of control you need to grant people appropriate permissions. Like you can add/remove people from the application but not give them appropriate access within it. Would love to learn how you’re thinking about the problem, send us a note if you want to talk more!

> I wonder what would be operational issues with this tool if this access was given for weeks / months instead of hours?

You can configure access duration flexibly with Sym. That being said, part of our philosophy is to make it easy for teams to transition to shorter access durations because the friction to re-grant access is reduced.

> I see your solution as pretty similar to Granted Approvals which are also open-source. What motivated you to start something of your own? I think Netflix open-sourced one solution for AWS too.

There are some great tools in the space for sure. Our motivation is to build a flexible engine for access and approvals that you can layer in to any modern platform stack.

Thanks - we’ve definitely seen Sym help our early customers safely distribute access decisions. Because the flows are managed in code, teams also get visibility into how these rules are defined and can contribute to improving them, as well as extend to new use cases.

Hey I’m Adam’s co-founder, we’d love feedback from the HN community on what we’ve been working on!

Author here, I went out on a limb and framed an argument for better approaches to cloud access management using the structure of the paper where Alan Turing introduced the Turing Test.

Itching for the follow up on how how to use organization-based conditions to make things simpler.

This is cool, I like the practicality and flexibility of being able to work with the data in Google Sheets without having to do any manual syncing.

I wrote a follow up post to this on SSH tunneling: https://news.ycombinator.com/item?id=22665037

This is a follow up to last week's post on session manager, a bunch of people had questions on SSH tunneling. Last week's post: https://news.ycombinator.com/item?id=22592875

Good call to watch out for this stuff. The examples in the repo we set up use the AmazonSSMManagedInstanceCore managed policy, which does not grant any S3 permissions, just various ssm, ssmmessages, and ec2messages permissions.

You can do this but it depends on your setup as to how. If you have AWS IAM users (not federated), then you can use MFA conditions in your policies as documented here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...

For federation you need to rely on the config in whatever your identity provider is, like Okta.

Yeah, this is the same deal. Session Manager will log your sessions which is pretty cool.

It does work with hardware tokens, IF you get your AWS IAM credentials using a hardware token. If you're using AWS IAM users then here are instructions: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...

If you're doing a federated login with Okta or another provider, you need to set up the hardware MFA there.

There is SSH tunneling support as well, will add an update on that soon.

Cool, will do!

I'd love to learn how you're using Session Manager or what other features/integrations you'd like to see us explore. Also if the terraform module packaging is useful. There are additional Session Manager features like port forwarding that I plan to write about soon.

This is an example we've been working that creates an Okta-managed user who can get in to a tagged EC2 instance using Session Manager. No bastion/sshd/security group ingress rules required. https://github.com/symopsio/terraform-okta-ssm-demo