Chef is Infrastructure-as-Code
Before DevOps, developers wrote applications to run on loosely defined servers that were owned, operated, and configured by a different SRE team. Developers wrote an application and then threw it “over the wall” to the operations team to make it work on their servers. There were many pitfalls to this approach: misconfigurations, inconsistent deployments, and missed handoffs between teams.
With the advent of DevOps, not only does developers’ code define the application, but code also defines the environment where the application runs. The specific configuration required for each server can be created and reproduced reliably based on the code that defines it – we call this “Infrastructure-as-Code” or IaC. With the addition of security and compliance into the DevOps mix, the “as Code” approach has been extended to “Policy-as-Code”. All of the audit and remediations in a tool like Chef InSpec™ are written in the same development languages that an application might contain and represent repeatable tests for use in deployment and operations.
Policy-as-code also comes with the added responsibility of managing these compliance operations like any other type of code. The same care that is taken to ensure your application code is secure from bad actors, needs to be applied to any “as-code” tools such as Chef, Terraform, Ansible or CloudFormation. When we talk of the software development lifecycle (SDLC), we protect application source code with approaches such as versioning, reviews and testing, security scanning, and by including other “trust” attributes. These techniques help us secure our code as it moves from development environments to its intended use in a production environment. We also expect that much of this is automated, so that processes rather than individuals are responsible for DevOps once in production.
This article is intended to provide high-level recommendations when using an “as Code” approach. Each organization’s usage may be different in the details and is unique to their business needs, so we will update this post with references to community best practices as well. Of course, you can also reach out to Progress Chef support and our partners directly if you need professional help in terms of implementing these recommendations.
“Infrastructure-As-Code” Code is No Different than Other Code
While Chef recipes, cookbooks, policies, and profiles are not “application code” developed by application developers, they are still coded artifacts – in fact, active content to be deployed on production systems – and need to be managed and protected appropriately. Chef content is infrastructure-as-code and compliance-as-code and is usually written in a domain specific language (DSL) interpretation of a programming language such as Ruby. Fundamentally, this content is no different than code written in Java, PowerShell, or any other interpreted programming language. This infrastructure code should be managed with similar coding practices including stringent testing, code versioning, people-led peer reviews, and CI/CD two-person rules. Chef Ruby-based content is executed in production systems in several ways:
- By running the InSpec CLI directly
- As part of an Automate scan job
- During the compliance phase in an Infra client run, either through Infra server or Chef Effortless, or
- As custom automation in CI/CD pipelines which may combine the above techniques.
Chef content is also like other coded artifacts in that it may be developed by people inside your organization, or it may come from a third party like a community influencer, another organization, or from us here at Chef. This content accelerates your journey to using the Chef platform quickly and across many different scenarios. Securing this content means inspecting this code borrowed from other places and assessing its fitness to do the job your organization wants to perform.
Best Practice Recommendations
So, what can you do to protect yourself and your code artifacts? Well, ideally, all the same things you’re doing already in your application software development. Here are our recommendations for securing your Chef Infrastructure-as-Code in two sections: securing content during development and using the content securely in production Chef server and command-line applications.
Securing cookbooks and InSpec profiles during development
- Know and the origin of your Chef infrastructure-as-code and version your content in a well-known, secure repository such as private Supermarket or GitHub where you can indicate the latest, approved version for both development and production environments.
- Follow domain-specific best practice in developing Ruby like commenting, testing for scale, and pulling secrets from the Chef or other vault (over hard-coding secrets like SSH parameters).
- Review the infrastructure-as-code files manually to make sure everything you want the Ruby to do is in there, and nothing else is. If you don’t understand a line from a third-party code fragment, ask the author or don’t use it.
- Use Chef and other automated tools like Test Kitchen or static application security tools (SAST) for code linting and testing. Humans easily miss small details, let the automation tools assist.
- Shift left by testing your coded artifacts in a pre-production environment, resolving any errors in the QA process before moving to production.
- Finally, utilize the two-person rule to only perform CI/CD actions – a solo operator should not be allowed to make changes without a second peer reviewing and approving the operation.
Securing the execution of cookbooks and InSpec profiles in production
- Ensure your Chef content is encrypted and signed (https://docs.chef.io/inspec/signing/).
- Use authentication to provide specific role-based access to your Chef servers. With Automate, you can incorporate your organization’s multi-factor authentication (MFA) tooling directly. For content repositories, also provide the correct level of access to update and no more. If extra tools to implement workflows such as Slack are used, follow the same principle of least access to secrets and content.
- Ensure servers like Automate have recent, valid certificates and that these certificates are rotated on a regular basis.
- Protect server machines with standard web application firewalls (WAF) and reverse proxies so they can filter, monitor, and block any malicious web-based traffic to and from these machines. Many customers operate Automate in an air-gapped environment for production DevOps against mission critical services in the enterprise.
- Routinely check your cloud, container and other on-prem environments where production Automate, and business services are located to ensure they are free from configuration errors that may pave way for attackers to compromise credentials or insert malicious code you’re your content repository – this is now a well-known example of a software supply chain attack.
- Finally, if you are automating a pipeline with Chef products inside, ensure that you are using the latest application versions and content from your validated repository. Check the automation logs and set alerts for unanticipated exceptions.
The Chef platform plus content from the community covers a broad number of scenarios and is very flexible. We hope you find this article to be a good starting point to drive awareness and change within your organization as you harness the power of DevSecOps.
Related articles
Reducing Misconfiguration Risks Through DevOps Best Practices
12 Common DevSecOps Definitions
7 Benefits of Policy as Code
A Practical Guide to Make DevSecOps an Automated Reality
What is Compliance as Code? The New Frontier in Compliance Automation
