Infrastructure as Code
Infrastructure as Code (IaC) is a process for managing and configuring infrastructure through text files in a human & machine readable format. IaC has seen a massive uptake and transformation due to cloud adoption driven by the ability to rapidly prototype and easily scale.
Benefits of Infrastructure as Code
The most common IaC strategy is declarative – allowing developers to store a definition of their virtual infrastructure in plain text files that covers all of the configuration required to deploy a service. Using an IaC tool, this definition can be applied to the target environment automating the deployment and configuration of all infrastructure. As plain text files, definitions can be stored in version control such as GIT following the same processes as application source code.
One of the key philosophies of IaC is that your infrastructure should always reach the same end state, irrespective of the initial state. Put simply, it is the job of the IaC tool to determine the current state of the system, the ordered sequence of steps to reach the target state, and then execute these steps. Idempotency ensures that re-applying the definition will result in the same
How did we get here?
When infrastructure was largely persistent, it was manageable to maintain build guides, manually deploy changes, restrict infrastructure changes to specific teams. Today, enabled by cloud, we need the power to rapidly deploy and configure infrastructure, and a manageable way to document the fine details.
Remember those bash scripts that you’d cobble together after painstakingly doing the same thing for a 10th time?
What is happening under the hood?
Each IaC tool is different, depending on it’s strategy, and the tool/service it is talking to, but fundamentally, there is a common sequence along these lines:
For each setting/service/vm/etc:
If already configured correctly, next
If unsuccessful, handle the error
When you write your own scripts, there is a lot of boilerplate code and error cases that you need to allow for to make something really versatile. Trying to create a directory that already exists in a bash script will result in an error unless you pass the right flag to ignore it. IaC tools bring these kinds of checks out of the box. They can even roll back to a previously known state, or skip a failed configuration and move on based on what you are doing.
IaC brings another powerful feature – dependency detection – which can be used to automatically manage the order of creation of resources, as well as determine which need to be recreated as part of a change deployment.
IaC allows for rapid repeatable creation/destruction of resources. This allows for easy development of automated, isolated testing. It also allows for cost reduction opportunities such as automatically (or manually) creating and destroying testing/dev/staging environments
IaC opens the door for version management that has never existed for infrastructure. Using fully declarative language stored in GIT allows developers to leverage PRs, code reviews, revisions and rollbacks as they are accustomed to from application code. Further, idempotency allows for these templates to be the source of a CI/CD pipeline used to automate the deployment and upgrade of entire environments.
DevOps is a development and release methodology, but is often associated with IaC due to the many benefits. IaC enabled Infrastructure to now be completely created and managed using code. IaC removed the friction and toil associated with teams manually provisioning and managing fleets of servers, databases, operating systems, containers and at this point, all infrastructure associated with software applications. Dev and Ops team are no longer separate teams, but rather working together to build and scale applications together.
There are many great IaC tools to meet a variety of requirements, from open source to enterprise support. They each have primary strengths, but are versatile enough to do almost anything you need.
Ansible – Traditionally a configuration management tool, now with support for all major clouds.
Terrafrom – More infrastructure focussed and takes full advantage of declarative language, including support for rolling upgrades and other important features.
Cloudformation – An AWS service for IaC supporting their cloud only. This can be a good option if you know you plan to stay with one provider.
Paving the path to Security as Code
Security as Code builds off the gains that organizations have seen from IaC. Security as code similarly sees a migration to security and policy as code to remove the toil and friction associated with securing software in an IaC mindset. Security and policy as code began with standard software testing of areas like permission boundaries. These unit and functional tests were Security as Code before being labeled as such. Security as Code also rose out of the desire for automation from internal and external red teams and pentesters to automate all things. Known as DevSecOps or DevOpsSec, this methodology has become the way organizations can enable collaboration, agility and security, early and often across their entire infrastructure.
When moving to a Security as Code model, there are a number of key benefits that are realized across the organization. Security as Code tightly couples application development with security management, while simultaneously allowing your developers to focus on core features and functionality, and simplifying configuration and authorization management for security teams. This improves collaboration between Development and Security teams and helps nurtures a culture of security across the organization. Security as Code helps simplify and centralize user and data access reducing toil and further providing visibility.
Access and policy changes can now be tracked, and requests for changes can be self service. Each test, scan or policy that is integrated results in problems getting uncovered sooner so they can be addressed before others find them. Dev and Security teams are no longer trying to address minor to complex to systemic issues after a new feature or functionality is “code complete”. With the advent of Security as Code libraries, application development can be decoupled from the fraught process of implementing custom authorization to reflect business policies.
Security as Code with Cyral
The principles of Security as Code and API-first have been at the core of design and development at Cyral. We have embraced cloud-first, everything as code and API-first design to meet our customers where they are, or want to be. Our commitment to Security as Code starts first with building a security product that is developer friendly. We have designed our product to naturally fit into existing development workflows. Our application can be easily deployed as part of your testing, staging and production environments to enhance tracing and security at each step of the way. To learn how Cyral can help your organization make this critical transformation, register for a demo.
Data Loss Prevention (DLP)
In the context of security, Data Loss is any event that causes either unintended exposure of data beyond the scope of granted rights or malicious …
Threat Modeling With DREAD
DREAD is a threat modeling program developed by Microsoft and first published in Writing Secure Code 2nd edition in 2002 by David LeBlanc and Michael …