{"id":754,"date":"2022-06-11T18:12:22","date_gmt":"2022-06-11T08:12:22","guid":{"rendered":"https:\/\/sysmit.com\/cf22\/?p=754"},"modified":"2023-12-13T15:28:02","modified_gmt":"2023-12-13T05:28:02","slug":"sre-safer-infrastructure-as-code-iac","status":"publish","type":"post","link":"https:\/\/sysmit.com\/cf22\/sre-safer-infrastructure-as-code-iac\/","title":{"rendered":"SRE&#8217;s role in safer infrastructure-as-code"},"content":{"rendered":"\n<p>This article explores 2 simple ways for SREs to drive better practices and code hygiene within infrastructure-as-code (IAC) tooling like Terraform.<\/p>\n\n\n\n<p>Why bother? <\/p>\n\n\n\n<p>Because of its centrality to cloud infrastructure efficiency,<strong> <\/strong>it&#8217;s highly likely that you will get involved with an IAC problem at some point in your SRE career. <\/p>\n\n\n\n<p>I will mention Terraform from time-to-time as an adjunct to IAC. However, many of the issues will likely apply to similar IAC tools like Pulumi, AWS CloudFormation and more. <\/p>\n\n\n\n<p>Terraform helps automate large parts of platform work and cloud provisioning. However, despite its automation promise, <strong>the nature of Terraform work can generate ongoing maintenance toil<\/strong>.<\/p>\n\n\n\n<p>Let&#8217;s explore two optimizations for Terraform to reduce potential toil and risk burden.  <\/p>\n\n\n<h2 class=\"wp-block-heading\" style=\"font-size:clamp(16.834px, 1.052rem + ((1vw - 3.2px) * 0.975), 26px);\" id=\"keep-your-terraform-code-organized\">Keep your Terraform code organized<\/h2>\n\n\n<p>Yevginy &#8220;Jim&#8221; Brikman is a consultant at Gruntworks, specializing in Terraform, Hashicorp&#8217;s infrastructure provisioning tool. He learned a <a href=\"https:\/\/www.hashicorp.com\/resources\/lessons-learned-300000-lines-code\">few interesting things from writing 300,000 lines of Terraform code<\/a>.<\/p>\n\n\n\n<p>One of these learnings was that <strong>many teams keep their Terraform code as a single monolithic file<\/strong>. It&#8217;s mind blowing to consider this, but many engineering teams still have elements of legacy culture.<\/p>\n\n\n\n<p>He noted more than a few teams storing all the environment configurations (development, QA, testing, staging, and production) on one gigantic file. This led to several problems including:<\/p>\n\n\n\n<ul style=\"font-size:clamp(15.747px, 0.984rem + ((1vw - 3.2px) * 0.878), 24px);\">\n<li>difficulty finding the line of code that needed to be updated<\/li>\n\n\n\n<li>long wait times (5+ minutes) for the monolith Terraform code to execute <\/li>\n\n\n\n<li>an increased risk of red line errors getting missed, e.g. \u201cexecuting code but the database will be deleted\u201d<\/li>\n<\/ul>\n\n\n\n<p>An even more concerning issue was that everyone was given <em>admin <\/em>permission to edit .tf files. In other words, <strong>less experienced developers gain admin-level access and unwittingly make undesirable changes<\/strong> to production infrastructure.<\/p>\n\n\n\n<p>This may be an acceptable risk in more progressive organizations with a strong psychological safety apparatus. But having extensive experience in bureaucratic workplaces, I can tell you it&#8217;s not always wise.<\/p>\n\n\n\n<p>The latter will most certainly apply to more traditional work environments like finance, government, healthcare etc.<\/p>\n\n\n\n<p>In summary, <strong>a monolith Terraform file risks a minor change breaking everything<\/strong>. So make sure it doesn&#8217;t happen. And if it is happening, change it, pronto. <\/p>\n\n\n\n<p>Making a monolithic codebase is a thing that most teams don\u2019t plan to do, but it\u2019s happening if IAC consultants are finding them. Here are recommendations for banishing monolith risk:<\/p>\n\n\n\n<ol style=\"font-size:clamp(15.747px, 0.984rem + ((1vw - 3.2px) * 0.878), 24px);\">\n<li>Isolate each environment as a separate .tf file or folder<\/li>\n\n\n\n<li>Break down each environment into various components &#8211; database, VPC, frontend etc<\/li>\n\n\n\n<li>Make all the above components reusable<\/li>\n<\/ol>\n\n\n\n<p>Let&#8217;s quickly unpack #2 \u2014 VPC configuration changes maybe once or twice a year while frontend might change 10 times a day. By separating them, you\u2019re reducing the risk of 10 configuration changes a day affecting the more fragile VPC daily.<\/p>\n\n\n\n<p>Outcome: modular architecture with smaller components r<strong>educes the surface area for attacks and errors affecting uptime<\/strong>.<\/p>\n\n\n<h2 class=\"wp-block-heading\" id=\"safeguard-your-terraform-templates\">Safeguard your Terraform templates<\/h2>\n\n\n<p>There are 2 ways that Terraform templates make it into a software system: <\/p>\n\n\n\n<ol>\n<li>Platform engineers equip developers with Terraform templates <em>or<\/em><\/li>\n\n\n\n<li>Developers source their code templates if there is no platform support<\/li>\n<\/ol>\n\n\n\n<p>The latter brings with it an inherent risk. Both <strong>externally and internally sourced templates may have built-in vulnerabilities <\/strong>\u2014 sometimes by mistake, sometimes intentionally. <\/p>\n\n\n\n<p>The result remains the same: potential production-level risks may get overlooked and cause future downtime. <\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>An analysis done by Unit 42 of Palo Alto Networks in 2020 found 200,000+ vulnerabilities in IAC templates. <\/p>\n<\/blockquote>\n\n\n\n<p>The risk is greater for teams that give developers full responsibility for their IAC. I am not trying to undermine the efforts of developers here, but it&#8217;s an unfortunate reality.<\/p>\n\n\n\n<p>Let&#8217;s take the encryption standards of PCI for example. Since 2018, PCI (payment card industry) has made TLS 1.0 a non-compliant encryption. Hackers can intercept and listen to traffic encrypted by that protocol.  <\/p>\n\n\n\n<p>A 2021 study by Azure operators found that <strong>developers were still trying to launch services to production with TLS 1.0 encryption<\/strong>. Almost 3 years later, for services that handled financial data.<\/p>\n\n\n\n\n\n<p>The message here isn\u2019t to avoid IAC if you aren&#8217;t a Terraform expert. It\u2019s that teams should consider the potential for risks in their deployments and mitigate them. <\/p>\n\n\n\n<p>Here are 3 methods that can lower the risk in IAC without stifling developers:<\/p>\n\n\n\n<ol style=\"font-size:clamp(15.747px, 0.984rem + ((1vw - 3.2px) * 0.878), 24px);\">\n<li>Institute <a href=\"https:\/\/www.srepath.com\/reduce-software-outage-risk-with-passive-guardrails#2-person-authentication\">2-person authentication<\/a> to assure the IAC has been coded correctly<\/li>\n\n\n\n<li>Have platform engineers or SREs write IAC templates with input from AppSec<\/li>\n\n\n\n<li>Set appropriate policy controls at the cloud service provider level<\/li>\n<\/ol>\n\n\n\n<p>Let&#8217;s now explore these 3 methods in more detail.<\/p>\n\n\n<h3 class=\"gb-headline gb-headline-f422af45 gb-headline-text\" id=\"1-institute-2person-authentication-of-iac-code\">1. <strong>Institute 2-person authentication of IAC code<\/strong><\/h3>\n\n\n<p>How would this work? One person would write the infrastructure code, either the platform engineer (if available) or developer. The other person would review and comment on the code&#8217;s veracity. <\/p>\n\n\n\n<p>SREs are well-positioned to be reviewers. It&#8217;s in their interest to pay attention, as <strong>improper IAC configuration and vulnerabilities can lead to downtime<\/strong>. This would consequently eat into their error budgets and impact their SLOs. <\/p>\n\n\n<h3 class=\"gb-headline gb-headline-c9af6078 gb-headline-text\" id=\"2-platformsre-teams-collaborate-with-security\">2. <strong>Platform\/SRE teams collaborate with security <\/strong><\/h3>\n\n\n<p>In many forward-looking organizations, SREs have have regular and direct interactions with security teams. If this is not the general case for yours, consider it for IAC collaborations. <\/p>\n\n\n\n<p>Security involvement in IAC development gives another perspective on vulnerabilities that can bring down the system in production. <\/p>\n\n\n\n<p>SREs can <strong>bake their learnings from security colleagues into IAC templates<\/strong> thus assuring security moving forward.<\/p>\n\n\n<h3 class=\"gb-headline gb-headline-de15cd41 gb-headline-text\" id=\"3-set-appropriate-policy-controls-at-the-cloud-provider-level\">3. <strong>Set appropriate policy controls at the cloud provider level<\/strong><\/h3>\n\n\n<p>Cloud (IaaS) providers may have in-built policy controls for the kind of infrastructure that <em>should<\/em> get provisioned e.g. Azure Policy. <\/p>\n\n\n\n<p>However, tread carefully with these as you don\u2019t want to restrict teams from deploying fast and often from overly onerous generic controls.<\/p>\n\n\n\n<p>I suggest that SREs <strong>evaluate developer deployment patterns and service criticality<\/strong> to create more appropriate and customized controls at the cloud provider level. <\/p>\n\n\n<h2 class=\"wp-block-heading\" style=\"font-size:clamp(16.834px, 1.052rem + ((1vw - 3.2px) * 0.975), 26px);\" id=\"conclusion\">Conclusion<\/h2>\n\n\n<p>By nature of their work, SREs need to have skill or understanding of IAC. This understanding needs to be constantly refined, as potential IAC vulnerabilities evolve over time. <\/p>\n\n\n\n<p>A typical SRE&#8217;s work is too varied for day-to-day IAC checks. Instead, they can provide timely guidance to developers and run monthly checks on the infrastructure code.<\/p>\n\n\n\n<p>This article hits only the tip of the IAC iceberg. There are many more considerations one could make to ensure the infrastructure is provisioned effectively and securely. As always, keep learning.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This article explores 2 simple ways for SREs to drive better practices and code hygiene within infrastructure-as-code (IAC) tooling like Terraform. Why bother? Because of its centrality to cloud infrastructure efficiency, it&#8217;s highly likely that you will get involved with an IAC problem at some point in your SRE career. I will mention Terraform from [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,5],"tags":[33,34,35],"_links":{"self":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/754"}],"collection":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/comments?post=754"}],"version-history":[{"count":28,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/754\/revisions"}],"predecessor-version":[{"id":5761,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/754\/revisions\/5761"}],"wp:attachment":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/media?parent=754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/categories?post=754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/tags?post=754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}