3 ms·

One thing I find interesting is that AWS has added some safeguards to the console to protect against exactly this, since it's presumably a very common issue. As

by cactus2093 6y ago

One thing I find interesting is that AWS has added some safeguards to the console to protect against exactly this, since it's presumably a very common issue. As of the last couple years when you make any S3 bucket open to the world you see a big warning about it. However if you're following the "industry best practices" and using something like Terraform to manage all your resources including IAM policies, you won't ever see the warnings. If you take a step back, it's somewhat bizarre that we've decided that having infra teams manage hundreds or thousands of lines of not-very-human-readable JSON across all the IAM resources they manage is the proper way to do things. I believe there are some linters that have some semantic understanding of IAM rules that could provide the same benefits, but at least when I last looked into it they weren't very mature and didn't match all of AWS' own rules. After experiencing some of the pains of managing a large Terraform configuration in the past, I've definitely started to wonder if we take the idea of "infrastructure as code" too literally. I think manually writing text-only configuration files for infrastructure should start to be seen as an anti-pattern as well, and we should mostly be working with better, more intuitive UIs for creating resources and then outputting the representation in some log format (which can then be read back by the same tool for reviewing/diffing, replayed in additional environments, rolled back, etc.)

echelon 6y ago
When infra isn't code, it's very hard to recreate. You can't possibly keep track of all the knobs changed by humans. It's easy to miss them. I like your idea of backing manually created resources with a machine log that can be replayed. Even better if it's editable and can be turned into something more concise and documented. Terraform is hard to read and manage. But it's better than manual, bespoke infra.
StreamBright 6y ago
>> we've decided that having infra teams manage hundreds or thousands of lines of not-very-human-readable JSON across all the IAM resources they manage is the proper way to do things. This is exactly why with few of my friends started to work on a tool that uses a typed language to express IaC. We can leverage and or relations for AWS objects. One quick example. S3 resource is PublicWebsite or ForwardOnly or PrivateBucket. The individual resources then have a bunch of mandatory properties (using and relationship between them). It is much easier to read and we have reduced the number of lines of code that we need to grasp to understand a service significantly. It is also possible to remove options that you do not want to give to developers at all (for example PublicWebsite is not a required option for most teams using S3). I really liked Terraform at the beginning when I thought they are going to improve significantly over the years but it did not happen. Instead they went down the same rabbit hole many other projects, lets invent a new language to express Iac. We do not need one. ML languages are perfectly capable to capture IaC and those languages are perfect fit while HCL lacks basic expressive power resulting in seggfaults/exceptions left and right. I still remember the first time we accidentally set both forward all requests to and website for an S3 bucket and we had to debug why Terraform just crashes with a meaningless error message. Imagine when you are trying to do something security related with such a tool. Not fun.
- cactus2093 6y ago
  Sounds really interesting, is there a public repo up yet to take a look at?
  - StreamBright 6y ago
    Could you reach out on Keybase or email?
calmlynarczyk 6y ago
CapOne sponsors, develops, and runs internally an open-source tool called [CloudCustodian](https://cloudcustodian.io/docs/index.html https://cloudcustodian.io/docs/index.html) (recently accepted into the CNCF) that analyzes cloud resources at runtime and notifies developers of items that are out of compliance. This allows you to identify issues with resources even if they drift from their templated configuration. It's a pretty good way to manage IT infrastructure at a very large scale rather than just relying on every dev to configure their infra perfectly and check in on the web console regularly to see if AWS raised any possible issues.

echelon 6y ago

When infra isn't code, it's very hard to recreate. You can't possibly keep track of all the knobs changed by humans. It's easy to miss them. I like your idea of backing manually created resources with a machine log that can be replayed. Even better if it's editable and can be turned into something more concise and documented. Terraform is hard to read and manage. But it's better than manual, bespoke infra.

StreamBright 6y ago

>> we've decided that having infra teams manage hundreds or thousands of lines of not-very-human-readable JSON across all the IAM resources they manage is the proper way to do things. This is exactly why with few of my friends started to work on a tool that uses a typed language to express IaC. We can leverage and or relations for AWS objects. One quick example. S3 resource is PublicWebsite or ForwardOnly or PrivateBucket. The individual resources then have a bunch of mandatory properties (using and relationship between them). It is much easier to read and we have reduced the number of lines of code that we need to grasp to understand a service significantly. It is also possible to remove options that you do not want to give to developers at all (for example PublicWebsite is not a required option for most teams using S3). I really liked Terraform at the beginning when I thought they are going to improve significantly over the years but it did not happen. Instead they went down the same rabbit hole many other projects, lets invent a new language to express Iac. We do not need one. ML languages are perfectly capable to capture IaC and those languages are perfect fit while HCL lacks basic expressive power resulting in seggfaults/exceptions left and right. I still remember the first time we accidentally set both forward all requests to and website for an S3 bucket and we had to debug why Terraform just crashes with a meaningless error message. Imagine when you are trying to do something security related with such a tool. Not fun.

cactus2093 6y ago
Sounds really interesting, is there a public repo up yet to take a look at?
- StreamBright 6y ago
  Could you reach out on Keybase or email?

calmlynarczyk 6y ago

CapOne sponsors, develops, and runs internally an open-source tool called [CloudCustodian](https://cloudcustodian.io/docs/index.html https://cloudcustodian.io/docs/index.html) (recently accepted into the CNCF) that analyzes cloud resources at runtime and notifies developers of items that are out of compliance. This allows you to identify issues with resources even if they drift from their templated configuration. It's a pretty good way to manage IT infrastructure at a very large scale rather than just relying on every dev to configure their infra perfectly and check in on the web console regularly to see if AWS raised any possible issues.