DOCSLIB.ORG

Security Smells in Ansible and Chef Scripts: a Replication Study

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Security Smells in Ansible and Chef Scripts: a Replication Study Security Smells in Ansible and Chef Scripts: A Replication Study AKOND RAHMAN, Tennessee Technological University, USA MD RAYHANUR RAHMAN, NC State University, USA CHRIS PARNIN, NC State University, USA LAURIE WILLIAMS, NC State University, USA Context: Security smells are recurring coding patterns that are indicative of security weakness, and require further inspection. As infrastructure as code (IaC) scripts, such as Ansible and Chef scripts, are used to provision cloud-based servers and systems at scale, security smells in IaC scripts could be used to enable malicious users to exploit vulnerabilities in the provisioned systems. Goal: The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code scripts through an empirical study of security smells in Ansible and Chef scripts. Methodology: We conduct a replication study where we apply qualitative analysis with 1,956 IaC scripts to identify security smells for IaC scripts written in two languages: Ansible and Chef. We construct a static analysis tool called Security Linter for Ansible and Chef scripts (SLAC) to automatically identify security smells in 50,323 scripts collected from 813 open source software repositories. We also submit bug reports for 1,000 randomly-selected smell occurrences. Results: We identify two security smells not reported in prior work: missing default in case statement and no integrity check. By applying SLAC we identify 46,600 occurrences of security smells that include 7,849 hard-coded passwords. We observe agreement for 65 of the responded 94 bug reports, which suggests the relevance of security smells for Ansible and Chef scripts amongst practitioners. Conclusion: We observe security smells to be prevalent in Ansible and Chef scripts, similar to that of the Puppet scripts. We recommend practitioners to rigorously inspect the presence of the identified security smells in Ansible and Chef scripts using (i) code review, and (ii) static analysis tools. The paper is accepted at the journal of ACM Transactions on Software Engineering and Methodology (TOSEM) on June 20, 2020. CCS Concepts: • Security and privacy → Software security engineering. Additional Key Words and Phrases: ansible, chef, configuration as code, configuration scripts, devops, devsecops, empirical study, infrastructure as code, insecure coding, security, smell, static analysis ACM Reference Format: Akond Rahman, Md Rayhanur Rahman, Chris Parnin, and Laurie Williams. 2018. Security Smells in Ansible and Chef Scripts: A Replication Study. 1, 1 (June 2018), 31 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Infrastructure as code (IaC) is the practice of using automated scripting to provision and configure their development environment and servers at scale [16]. Similar to software source code, recommended software engineering practices, Authors’ addresses: Akond Rahman, Tennessee Technological University, 1 William Jones Drive, Cookeville, Tennessee, USA, [email protected]; Md Rayhanur Rahman, NC State University, 890 Oval Drive, Raleigh, North Carolina, USA, [email protected]; Chris Parnin, NC State University, 890 arXiv:1907.07159v2 [cs.CR] 20 Jun 2020 Oval Drive, Raleigh, North Carolina, USA, [email protected]; Laurie Williams, NC State University, 890 Oval Drive, Raleigh, North Carolina, USA, [email protected]. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights forcomponents of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. © 2018 Association for Computing Machinery. Manuscript submitted to ACM Manuscript submitted to ACM 1 2 Rahman et al. such as version control and testing are expected to be applied to implement the practice of IaC. IaC tool vendors, such as Ansible 1 and Chef 2 provide programming utilities to implement the practice of IaC. The use of IaC scripts has resulted in benefits for information technology (IT) organizations. For example, the use of IaC scripts helpedthe National Aeronautics and Space Administration (NASA) to reduce its multi-day patching process to 45 minutes [3]. Using IaC scripts application deployment time for Borsa Istanbul, Turkey’s stock exchange, reduced from ∼10 days to an hour [23]. With IaC scripts Ambit Energy increased their deployment frequency by a factor of 1,200 [32]. The Enterprise Strategy Group surveyed practitioners and reported the use of IaC scripts to help IT organizations gain 210% in time savings and 97% in cost savings on average [25]. Despite reported benefits, IaC scripts can be susceptible to security weakness. In our recent work, weidentified security smells for Puppet scripts [37]. Security smells are recurring coding patterns that are indicative of security weakness, and requires further inspection [37]. We identified 21,201 occurrences of seven security smells that include 1,326 occurrences of hard-coded passwords in 15,232 Puppet scripts. Our prior research showed relevance of the identified security smells amongst practitioners as well: from 212 responses we observe practitioners to agree with148 occurrences. IT organizations may use other languages, such as Ansible, Chef, and Terraform 3, for which our previous categoriza- tion of security smells reported in prior work [37] may not hold. A replication of our prior work for other languages, such as Ansible and Chef, may have value for practitioners as well as for research as we study the generalizability and robustness of IaC security smells in a larger variety of contexts. A 2019 survey with 786 practitioners reported Ansible as the most popular language to implement IaC, followed by Chef 45 . As usage of Ansible and Chef is getting increasingly popular amongst practitioners, identification of security smells could have relevance to practitioners in mitigating insecure coding practices in IaC. Our prior research [37] is not exhaustive and may not capture security smells that exist for other languages. Let us consider Figure1 in this regard. In Figure1, we present an actual Ansible code snippet downloaded from an open source software (OSS) repository 6. In the code snippet, we observe the ‘gpgcheck’ parameter is assigned ‘no’, indicating while downloading the ‘nginx’ package, the ‘yum’ package manager will not check the contents of the downloaded package 7. Not checking the content of a downloaded package is related to a security weakness called ‘Download of Code Without Integrity Check (CWE-494) 8’. According to Common Weakness Enumeration (CWE), not specifying integrity check may help malicious users to “execute attacker-controlled commands, read or modify sensitive resources, or prevent the software from functioning correctly for legitimate users”. Existence and persistence of security smells similar to Figure1 in IaC scripts provide attackers opportunities to attack the provisioned system. We hypothesize through a replication [45] of our prior work, we can systematically identify security smells for other languages namely, Ansible and Chef. The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code scripts through an empirical study of security smells in Ansible and Chef scripts. We answer the following research questions: 1https://www.ansible.com/ 2https://www.chef.io/chef/ 3https://www.terraform.io/ 4https://info.flexerasoftware.com/SLO-WP-State-of-the-Cloud-2019 5https://www.techrepublic.com/article/ansible-overtakes-chef-and-puppet-as-the-top-cloud-configuration-management-tool/ 6https://git.openstack.org/cgit/openstack/openstack-ansible-ops/ 7https://docs.ansible.com/ansible/2.3/yum_repository_module.html 8https://cwe.mitre.org/data/definitions/494.html Manuscript submitted to ACM Security Smells in Ansible and Chef Scripts: A Replication Study 3 1 - name: Add nginx repo to yum sources list 2 yum_repository: 3 name:"nginx" 4 file:"nginx" Disabled ‘gpgcheck’: no integrity check 5 description:"NGINX repo" 6 baseurl:"{{ elastic_nginx_repo.repo}}" 7 state:"{{ elastic_nginx_repo.state}}" 8 enabled: yes 9 gpgcheck: no Fig. 1. An example Ansible script where integrity check is not specified. • RQ1: What security smells occur in Ansible and Chef scripts? • RQ2: How frequently do security smells occur for Ansible and Chef scripts? • RQ3: How do practitioners perceive the identified security smell occurrences for Ansible and Chef scripts? We build on prior research [37] related to security smells for IaC scripts on Puppet, and investigate what security smells for two languages used to implement the practice of IaC, namely Ansible and Chef. We conduct a differentiated replication [19][21] of our prior work [37], where we use a experimental setup different to our prior work using Ansible and Chef scripts. We apply qualitative analysis [54] on 1,101 Ansible scripts and 855 Chef scripts to determine security smells. Next, we construct a static analysis tool called Security Linter for Ansible and Chef scripts (SLAC)[37] to automatically identify the occurrence of these security smells in 14,253 Ansible and 36,070 Chef scripts collected by respectively, mining 365 and 448 OSS repositories.
Load more

Recommended publications
  • A Study of the Effectiveness of Cloud Infrastructure
    A STUDY OF THE EFFECTIVENESS OF CLOUD INFRASTRUCTURE CONFIGURATION A Thesis Presented to the Faculty of California State Polytechnic University, Pomona In Partial Fulfillment Of the Requirements for the Degree Master of Science In Computer Science By Bonnie Ngu 2020 SIGNATURE PAGE THESIS: A STUDY OF THE EFFECTIVENESS OF CLOUD INFRASTRUCTURE CONFIGURATION AUTHOR: Bonnie Ngu DATE SUBMITTED: Spring 2020 Department of Computer Science Dr. Gilbert S. Young _______________________________________ Thesis Committee Chair Computer Science Yu Sun, Ph.D _______________________________________ Computer Science Dominick A. Atanasio _______________________________________ Professor Computer Science ii ACKNOWLEDGEMENTS First and foremost, I would like to thank my parents for blessing me with the opportunity to choose my own path. I would also like to thank Dr. Young for all the encouragement throughout my years at Cal Poly Pomona. It was through his excitement and passion for teaching that I found my passion in computer science. Dr. Sun and Professor Atanasio for taking the time to understand my thesis and providing valuable input. Lastly, I would like to thank my other half for always seeing the positive side of things and finding the silver lining. It has been an incredible chapter in my life, and I could not have done it without all the love and moral support from everyone. iii ABSTRACT As cloud providers continuously strive to strengthen their cloud solutions, companies, big and small, are lured by this appealing prospect. Cloud providers aim to take away the trouble of the brick and mortar of physical equipment. Utilizing the cloud can help companies increase efficiency and improve cash flow.
    [Show full text]
  • Lessons Learned from a Large-Scale Infrastructure As Code Project
    PowerShell Conference Europe 2019 Hannover, Germany June 4-7, 2019 Lessons learned from a large-scale infrastructure as code project Platinum Sponsor Mark Warneke After this Session - I am able to develop a mature “Infrastructure As Code” project from scratch using a Test-Driven development approach, avoiding common pitfalls and getting a heads up in necessary considerations, tools and best practices - I can build sophisticated Azure Release Pipelines that leverage advanced testing scenarios using Azure Resource Manager Templates, PowerShell tooling to support an advanced “Infrastructure As Code” project @MarkWarneke Agenda Introduction Architecture Demo @MarkWarneke By viewing cloud computing as a starting point for IT automation, companies may be able to have it all: scalability, agility, flexibility, efficiency, “ and cost savings. But that’s only possible by building up both automation and cloud capabilities. – McKinsey @MarkWarneke“ What is the challange? Speed Control Agility @MarkWarneke Why change? Servers Services @MarkWarneke Paradigm shift Enforce/Control Enable/Support Controlled & central responsibility Freedom & delegated responsibility @MarkWarneke What organization want Secure, predictable, and flexible Control service delivery and operations capability (end to end traceability). Faster business innovation through Innovation adoption of cloud services. Business agility and reduced time-to- Speed/Agility market through efficient DevOps teams. Costs Efficient use of public cloud scale. @MarkWarneke DevOps benefits based on research Source: 2018 State of DevOps Report DORA @MarkWarneke A Cloud Center of Excellence (CCoE) is a cross- functional team of people responsible for developing and managing the cloud strategy, “governance, and best practices that the rest of the organization can leverage to transform the business using the cloud.
    [Show full text]
  • Adoption, Support, and Challenges of Infrastructure-As-Code: Insights from Industry
    Adoption, Support, and Challenges of Infrastructure-as-Code: Insights from Industry Michele Guerriero,1 Martin Garriga,2 Damian A. Tamburri,3 Fabio Palomba4 1Politecnico di Milano, Italy 2Jheronimus Academy of Data Science & Tilburg University, The Netherlands 3Jheronimus Academy of Data Science & Eindhoven University of Technology, The Netherlands 4University of Zurich, Switzerland [email protected], [email protected], [email protected], palomba@ifi.uzh.ch Abstract—Infrastructure-as-code (IaC) is the DevOps tactic semi-structured interviews in as many companies to distill: (1) of managing and provisioning infrastructure through machine- how practitioners currently develop infrastructural code — that readable definition files, rather than physical hardware config- is, the best/bad practices experienced by the practitioners as uration or interactive configuration tools. From a maintenance and evolution perspective, the topic has piqued the interest of IaC blueprints grow in size and maintenance costs [8], (2) practitioners and academics alike, given the relative scarcity of what is the automatic support available — that is, pros and supporting patterns, best practices, tools, and software engineer- cons of using existing tools in practice, and (3) the challenges ing techniques. Using the data coming from 44 semi-structured reported by the practitioners via direct experience — that is, interviews in as many companies, in this paper we shed light the research and industrial avenues that practitioners perceive on the state of the practice in the adoption of IaC and the key software engineering challenges in the field. Particularly, as worthy of investigation in the near future. we investigate (i) how practitioners adopt and develop IaC, (ii) Data on the above points reveals a number of results as well which support is currently available, i.e., the typically used as valuable avenues for further work.
    [Show full text]
  • INFRASTRUCTURE AS CODE–FINAL REPORT John Klein, Phd and Douglas Reynolds December 2018
    INFRASTRUCTURE AS CODE–FINAL REPORT John Klein, PhD and Douglas Reynolds December 2018 1 Introduction This report concludes work on Research Project 6-18 518 Feasibility of Infrastructure as Code, summarizing the problem addressed by the research, the research solution approach, and results. 1.1 Background 1.1.1 What Is Infrastructure as Code? Infrastructure as code (IaC) is a set of practices that use “code (rather than manual commands) for setting up (virtual) machines and networks, installing packages, and configuring the environment for the application of interest” [3]. The infrastructure managed by this code includes both physical equipment (“bare metal”) and virtual machines, containers, and software-defined networks. This code should be developed and managed using the same processes as any other software; for example, it should be designed, tested, and stored in a version-controlled repository. Although information technology (IT) system operators have long employed automation through ad hoc scripting of tasks, IaC technology and practices emerged with the introduction of cloud computing, and particularly infrastructure-as-a-service (IaaS) technology. In an IaaS-based envi- ronment, all computation, storage, and network resources are virtualized and must be allocated and configured using application programming interfaces (APIs). While cloud service providers furnish management consoles that layer an interactive application on top of the APIs, it is not practical to use a management console to create a system with more than a couple of nodes. For example, creating a new virtual machine (VM) using the Amazon Web Services management console requires stepping through at least five web forms and filling in 25 or more fields.
    [Show full text]
  • Adopting 'Infrastructure As Code' Misha Zynovyev (GSI)
    Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) adopting 'infrastructure as code' to run HEP applications Misha Zynovyev ([email protected]) Dennis Klein ([email protected]) Victor Penso ([email protected]) HEPiX Spring 2011 GSI, Darmstadt, 5th of May 2011 Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) acknowledgements Dr. Peter Malzacher Bastian Neuburger Christopher Huhn Dr. Stefan Haller Helge Brust Oliver Wirth Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) outline of the talk our mission statement current approaches to infrastructure management our approach to running HEP applications describing infrastructure with code our playgrounds results outlook Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) clarification target audience: developers, system administrators and infrastructure providers you accept the benefits of virtualization presented concepts are transparent to users1 this is not about how to build the Infrastructure-as-a-Service (IaaS) clouds, but about efficient ways to use them 1nevertheless users can have as much control of details as they can cope with Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) our mission statement we want to simplify deployment and operation of scientific computing applications and their infrastructure by describing everything in code furthermore, we need a mechanism which will allow us to use external resources provided by IaaS clouds in a transparent way Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) deploying infrastructure manual (with OS tools, text-editor):
    [Show full text]
  • CV - Russell Dunphy [email protected] | 07849465404 |
    CV - Russell Dunphy [email protected] | 07849465404 | https://www.linkedin.com/in/rsslldnphy/ An experienced software developer, technical leader, and manager, with a love of functional ​ ​ ​ ​ ​ ​ ​ programming and coding as language. Came to programming by a somewhat unusual route: ​ ​ ​ a first class degree in Creative Writing. I see people, teams, code, and infrastructure as an interconnected ecosystem, and enjoy ​ ​ tending that ecosystem by sitting at the intersection of them all: doing people management, process optimisation, architecture, and coding as and when needed. I also enjoy developing long-term technical strategy, taking into account how this ecosystem fits into the wider business ​ ​ context, and finding sustainable, iterative ways to implement it. I’ve managed teams ranging in size from two to twelve, including developers, data scientists, scrum masters and testers. I’ve worked with a number of languages, most recently Clojure, ​ ​ Clojurescript, and Javascript/Typescript, and love learning more. I’m happy wrangling ​ ​ ​ ​ ​ infrastructure, doing backend work, or building frontend features. Most of all I like finding ways to make these different levels of the stack, and the people who work on them, form a cohesive whole. Employment Head of Engineering - HealthUnlocked Jun 2016 - Present ​ HealthUnlocked is social network for health, with around 3-4 million unique sessions per month. As Head of Engineering I am responsible for managing the tech team; for recruitment; for setting technical strategy for the organisation;
    [Show full text]
  • Devops: Introducing Infrastructure-‐As-‐Code
    DevOps: Introducing Infrastructure-as-Code Elisabetta Di Nitto, Damian A. Tamburri*, Michele Guerriero*, Matej Artac+, Tadej Borovsak+ *Politecnico di Milano +XLAB Corp. Roadmap o Session 1: DevOps In a Nutshell o Break! (5 mins) o Session 2: Infrastructure-as-code Explained through TOSCA o Session 3: Our proposal to connect Dev and Ops: the DICER tool Session 1 DevOps In a Nutshell Dev & Ops: the classical roles Dev focuses on o Developing features o Changing requirements o Releasing products Ops focuses on o Offering services o Providing guarantees and stability Dev vs. Ops “The system works correctly in the development machine but it does not on the operation machine” “10 days after successful deployment of last release, the system is overloaded” Who is guilty? Dev– team, or –Ops team? The problem: two disconnected groups • Dev works to apply releases • Ops resists to releases • Dev does not pay attention • Ops is aiming at to QoS guarantees guaranteering QoS • Changes are fundamental for the business! • QoS guarantees are needed too! DevOps • What is it: “Practices or tools that bridge the gap between development and operations” • Goal: Creates a collaborative mindset where a single team performs Dev and Ops àthe team must contain differentiated competences, background, etc. • Requires: • Culture management; • Automation tools; • Organisational as much as technical metrics • Continuous sharing artifacts, procedures, languages, approaches… DevOps Need 1: Process Alignment! - Unified Processes - Unified tooling Before DevOps Development
    [Show full text]
  • Infrastructure As Code (Iac) to Reduce Provisioning Time by 65%
    Infrastructure as Code (IaC) to Reduce Provisioning Time by 65% Credits Deepak Jayagopal Kanapathi Raja Sathya Narayanan Higher Elasticity And Scale of Infrastructure Has Made it Cumbersome to Manually Provision Even After The Adoption of Cloud Computing Legacy manual provisioning Cloud manual provisioning Evolution of of infrastructure infrastructure • Traditionally, Infrastructure provisioning has • Using cloud computing (Infrastructure as provisioning always been a manual process. a Service), an instant computing • Teams would rack and stack the servers and infrastructure could be provisioned and will manually configure them. managed over the internet. • Finally, they will install the application over • Cloud computing reduced the need for that hardware. high upfront capital expenditure as well • This used to be a slow process and there were as maintenance costs. a lot of accuracy and consistency issues. Infrastructure as Code (IaC) Infrastructure as Code IaC allows DevOps IaC takes cloud (IaC) is the process of engineers to view computing to its provisioning and complex maximum potential by managing the entire infrastructure in a automating the infrastructure through a codified way. manual, error-prone series of software. provisioning tasks. Cloud infrastructure solved many issues pertaining to the legacy provisioning methods. However, there are still issues persisting with manual provisioning of cloud infrastructure. Confidential & Restricted 2 Major Challenges with Manual Provisioning of Cloud Infrastructure DSPs across the globe have a Time consuming in Higher cost great necessity to adopt a provisioning infrastructure strong cloud strategy to deliver digital services across In the case of huge infrastructures, the time Cost is calculated per hour by taken to manual cloud provisioning gets cloud vendors.
    [Show full text]
  • Co-Evolution of Infrastructure and Source Code - an Empirical Study
    Co-evolution of Infrastructure and Source Code - An Empirical Study Yujuan Jiang, Bram Adams MCIS lab Polytechnique Montreal, Canada Email: yujuan.jiang,bram.adams @polymtl.ca { } Abstract—Infrastructure-as-code automates the process of have a high coupling with source code and test files, which configuring and setting up the environment (e.g., servers, VMs means that developers and testers need to perform a certain and databases) in which a software system will be tested and/or effort to maintain the build system files as the code and tests deployed, through textual specification files in a language like evolve. Based on these findings, we conjecture that IaC could Puppet or Chef. Since the environment is instantiated auto- run similar risks and generate similar maintenance overhead matically by the infrastructure languages’ tools, no manual as regular build scripts. intervention is necessary apart from maintaining the infrastruc- ture specification files. The amount of work involved with such In order to validate this conjecture, we perform an empir- maintenance, as well as the size and complexity of infrastructure ical case study on 265 OpenStack projects. OpenStack is an specification files, have not yet been studied empirically. Through ecosystem of projects implementing a cloud platform, which an empirical study of the version control system of 265 OpenStack requires substantial IaC to support deployment and tests on projects, we find that infrastructure files are large and churn frequently, which could indicate a potential of introducing bugs. virtual machines. The study replicates the analysis of McIntosh Furthermore, we found that the infrastructure code files are et al.
    [Show full text]
  • Infrastructure As Code Handbook
    THE INFRASTRUCTURE AS CODE HANDBOOK Best practices, tools, and AWS CloudFormation scripts you can use to implement IaC for your organization www.thorntech.com Copyright © 2018 | THORN TECHNOLOGIES All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the publisher. THE INFRASTRUCTURE AS CODE HANDBOOK Contents 1 FIVE REASONS WHY YOU SHOULD IMPLEMENT INFRASTRUCTURE AS CODE NOW 2 SIX BEST PRACTICES TO GET THE MOST OUT OF IAC 3 FIFTEEN IAC TOOLS YOU CAN USE TO AUTOMATE YOUR DEPLOYMENTS 4 WHAT IS AWS CLOUDFORMATION AND HOW CAN IT HELP YOUR IAC EFFORTS? 5 HOW AWS CLOUDFORMATION WORKS AND HOW TO CREATE A VIRTUAL PRIVATE CLOUD WITH IT 6 HOW TO INCORPORATE S3, EC2, AND IAM IN A CLOUDFORMATION TEMPLATE 7 HOW TO CREATE A REDSHIFT STACK WITH AWS CLOUDFORMATION 3 www.thorntech.com [email protected] THE INFRASTRUCTURE AS CODE HANDBOOK 5 reasons why you should implement infrastructure as code now INFRASTRUCTURE AS CODE CAN HELP AVOID CLOUD DEPLOYMENT INCONSISTENCIES, INCREASE DEVELOPER PRODUCTIVITY, AND LOWER COSTS There’s no doubt that cloud computing has had a major impact on how companies build, scale, and maintain technology products. The ability to click a few buttons to provision servers, databases, and other infrastructure has led to an increase in developer productivity we’ve never seen before. While it’s easy to spin up simple cloud architectures, mistakes can easily be made provisioning complex ones. Human error will always be present, especially when you can launch cloud infrastructure by clicking buttons on a web app.
    [Show full text]
  • Microsoft Azure: Infrastructure As Code
    Microsoft Azure: Infrastructure as Code WorkshopPLUS Duration: 3 Days Focus Area: Change and Configuration Management Difficulty: 300 - Advanced Overview Key Takeaways Get hands-on with Infrastructure as Code by learning how Course Material to author and submit code from common tools into Azure • Azure Templates Resource Manager (ARM). In this course you can choose learning paths for integrating with Microsoft 1st party and • Visual Studio Code 3rd party open source including: Azure Templates, Hands-on Labs Terraform, Ansible, Azure Automation, and Desired State • Most of the concepts covered above will be supported Configuration. You’ll walk away understanding basic and by hands-on labs and demos advanced techniques for programmatically instructing Azure how to build-out and update your environments. • Utilize tools that integrate with Azure Objectives Agenda After completing this training, students will be able to: Day 1 • Understand what infrastructure as code means • Introduction to Infrastructure as Code • Learn about the different tools available to manage • Tools code lifecycle • Overview of Azure • How to manipulate & reference code Day 2 • Optional Module(s) • Understand the structure of an Azure Template Day 3 • Set resource deployment order • Optional Module(s) • Onboard Azure Automation & DSC • Q&A, as time permits • Learn to leverage & integrate third-party, open source software to develop the Azure environment Plan for 3 full days. Early departure on any day is not • Describe Ansible fundamentals, dynamic inventory and recommended. deploy Azure resources • Learn Terraform best practices for deploying Azure resources • Integrate Terraform with continuous integration / continuous delivery 2019 © Microsoft Corporation. All rights reserved. This data sheet is for informational purposes only.
    [Show full text]
  • HASHICORP TERRAFORM and RED HAT ANSIBLE AUTOMATION Infrastructure As Code Automation
    HASHICORP TERRAFORM AND RED HAT ANSIBLE AUTOMATION Infrastructure as code automation OVERVIEW INTRODUCTION As organizations modernize their application delivery process and adopt new tools to make them more efficient, infrastructure as code (IaC) has become a critical practice. IaC is an umbrella term, usually referring to a broad range of tools, operational frameworks, and a rich ecosystem. In this piece, we describe what is meant by infrastructure as code and how HashiCorp Terraform and Red Hat® Ansible® Automation can be used as a foundation for an IaC initiative. WHAT IS INFRASTRUCTURE AS CODE? In the last four decades, most approaches to infrastructure management have relied on graphical and command-line user interfaces that human operators have used to initialize or modify system configurations. These approaches are prone to human error. The process carried out by an operator might be documented by a checklist or a memorized routine without enforced oversight or iterative versioning. In contrast, the IaC approach promotes formalized, standardized, and automated operational processes — and dictates that these operational processes are documented as configuration files or programming code. By treating infrastructure as code, IT organizations can automate management tasks while using the best practices of software development, including code review and version control. This approach mitigates management complexity by breaking down a task into smaller, more manageable processes, controlling the execution of code, and effortlessly maintaining up-to-date documentation. The IaC approach also reduces operational risks by allowing multiple subject matter experts to peer review the code and by saving all the previous revisions of a codified infrastructure, enabling previous versions to be restored in case of mistakes.
    [Show full text]