securiy

Crap, I didn't know these acronyms before either and now I've turned into a Gartner shill :sob:

IAM users are still needed in large orgs because of legacy tooling that only accepts access key ID / secret access key sigh.

I wanted to share a recent blog post we've put together on creating an IAM Audit Trail with IAMbic (www.github.com/noqdev/iambic) with support for Cloudtrail logging and attribution. If you've ever found IAM changes in AWS challenging to track, this is for you. In IAMbic, all changes get their own Git commit, regardless if they were made using Terraform/Cloudformation/Console Clicking/etc. The new CloudTrail logging integration which provides an even deeper insight into every modification all within Git.

Give it a read, and please give us feedback!

Full disclosure: I'm one of the authors of the tool mentioned in the video, IAMbic.

The premise: Cloud IAM can get messy as your organization scales and you need to enforce compliance and security policies. Existing tools are often siloed and don’t give you a clear picture of your IAM state across different teams and platforms. IAMbic solves this problem by syncing your IAM state with version control, regardless of how you manage your IAM. It captures your IAM changes in Git as human-readable templates that you can track, review, and modify. If you just want to use IAMbic to gain visibility in your environment, you can stop here. But, you can also use IAMbic to apply changes to the cloud via Git workflows and prevent drift on selected resources, because these files in version control are bi-directional.

Right now, IAMbic supports AWS IAM (Users, groups, roles, policies), Identity Center, and Service Control Policies, Google Workspace IAM, Azure AD IAM, and Okta IAM. Our vision is to support other cloud providers, and give you a unified and flexible way to manage your cloud identities.

I'd love to hear your feedback on the approach.

Hello everyone!

We are working on an open-source IAM-as-code solution called IAMbic, and recently added AWS Service Control Policy support (AWS guardrails, typically used for compliance) seen in the attached blog.

IAMbic represents your IAM in Git as YAML Files (called iambic templates). An example repository of templates managed by IAMbic is at https://github.com/noqdev/iambic-templates-examples. The goal is that you can download IAMbic, and go from your cloud to code in ~10 minutes without needing to write any code. Any changes you make (via clicking in the cloud console, running `terraform apply`, etc) are captured by IAMbic and updated in Git, so you have a running Git history of all IAM changes over time, and Git is an eventually consistent, reliable source of truth for permissions.

IAMbic templates are bi-directional, so when you want to start managing identities in IAMbic (like cookie-cutter engineering IAM roles or AWS SSO permission sets), You go through a GitOps workflow, get approval, and instruct IAMbic to apply the changes. We have some examples in our IAMOps Philosophy docs here: https://docs.iambic.org/reference/iamops_philosophy. If you want resources to be solely managed by IAMbic, you can instruct IAMbic to prevent drift on these resources.

You can also declaratively define temporary access or permissions in the format (Example use cases: "I want userA to have access to the Salesforce app in Okta for 12 hours" or "I want to have S3 permissions to BucketA on the engineering role on the prod AWS account until DATE").

What are your thoughts? How can we make this better?

Hey everyone. I wrote a blog post for those of us that might struggle to manage permissions in AWS Identity Center (SSO), and who find that existing tooling like Terraform and CloudFormation lack visibility into your actual IAM state, and require too much work to manage for permissions. Would love your feedback: https://www.noq.dev/blog/tailor-aws-identity-center-sso-perm...

The tutorial shows how to do the following with IAMbic: - Get a complete, eventually-consistent accounting of your cloud IAM in version control in under an hour, all without writing any code - Customize Permission Set Access Rules and IAM permissions per account, in a centralized GitOps workflow - Prevent drift on IAM resources you want to be exclusively managed via IAMbic, like sensitive permission sets

Hope you find this helpful!

Struggling with AWS config changes taking down prod services? Wish to give more permissions in dev/test but less in prod? Check out this blog on IAMbic an open-source tool to tame multi-account AWS IAM chaos

Hey everyone, I'm Curtis. I’m excited to announce the open-source launch of IAMbic (IAM, but in code), a multi-cloud control plane that simplifies IAM management in a GitOps workflow. It’s like Terraform for Cloud IAM, but way easier. See for yourself on GitHub (https://github.com/noqdev/iambic).

During my time on Netflix’s Cloud Security team, we faced the challenge of managing IAM at scale. We had to manage shared user roles with different permissions for dev and prod accounts, grant temporary access to developers to test new services (which we forgot to remove), protect sensitive policies from misconfiguration, and help users with IAM. Things only got more complex as we added more employees, AWS accounts, applications, and cloud resources. It was like playing Clue to find IAM misconfigurations, Jenga to carefully remove temporary/unused permissions, and Tetris to organize the right access rules for each user and app. These tasks were time consuming and made us dread being on-call.

As permissions piled up, the mental burden of maintenance increased, and security risks and mistakes grew over time. We knew it was only a matter of time before an over-provisioned developer caused critical infrastructure to fail, or even worse, for a sensitive application role to be compromised.

We created IAMbic to solve these problems by making it easy to unify all cloud identities, going beyond access to manage complex cloud permissions, tracking access all the way from users to cloud resources, and presenting everything in a human-readable, as-code, and open-source format.

IAMbic supports bidirectional syncing and round-trip capabilities in a GitOps workflow, and includes the following key features:

- Universal Cloud Identity: Integrate identities from AWS IAM and Identity Center, Okta, Azure AD, and Google Workspace with more to come. - Dynamic AWS Permissions: Multi-account roles with different permissions and access rules on different accounts. - Temporary Access: Declaratively define and automate expiration dates for cloud access, fine-grained permissions, and identities. - Drift prevention: Prevent out-of-band changes to IAM resources you want to be exclusively managed via IAMbic, like cookie-cutter roles or sensitive identity provider groups.

We’re just getting started on our journey to change the way cloud IAM is managed. We’re huge fans of open source and eager to grow together through your feedback and contributions. Try out IAMbic by following the Getting Started guide (https://docs.iambic.org/getting_started/). We’d love to chat and hear about your experiences in our Slack community (https://communityinviter.com/apps/noqcommunity/noq).

I considered writing it in Go, but my team is Python-centric. Tornado was chosen back in 2018 because it was one of the better fully featured async web frameworks. The original ConsoleMe was server-side rendered, and Tornado offered support for these types of templates.

ConsoleMe's frontend is now fully React and could be ported away from Tornado, but it'd be a pretty large effort.