Chef is Infrastructure-as-Code
“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.
Best Practice Recommendations
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.