ChefConf Takeaways

This past week, I was in Seattle, Washington as an attendee of ChefConf 2019. I learned a lot about Chef, how other teams organize and other best practices for DevOps, Agile and every other buzzword. Here are my biggest takeaways.

Code is the common language

Despite Ruby being a weird language, code is easier to understand than an obscure technical specification for the security posture of an organization. Write your security controls using InSpec.

If you take a requirement that says “SSH directory for non-privileged user should not have world-writable files”, do you know exactly what permissions you need to set? Do you need to set the directory’s permissoins and the files?

describe file('/home/testuser/.ssh') do
    it { should exist }
    it { should be_readable.by 'other' }
    it { should_not be_writable.by 'other' }
    it { should_not be_executable.by 'other' }
end
describe file('/home/testuser/.ssh/authorized_keys') do
    it { should exist }
    it { should be_readable.by 'other' }
    it { should_not be_writable.by 'other' }
    it { should_not be_executable.by 'other' }
end
describe file('/home/testuser/.ssh/known_hosts') do
    it { should exist }
    it { should be_readable.by 'other' }
    it { should_not be_writable.by 'other' }
    it { should_not be_executable.by 'other' }
end

Not only do you know exactly what the requirements are, InSpec is easy to read and it lets you test the machine that has the requirements.

Documentation is important

This might be obvious. Write documentation for the code you write! But it’s more than that. You need to be transparent with what your code does, the infrastructure around it, what version of Chef Workstation, the IP addresses of the Chef servers, etc. This will help you gain an internal community, trust in what you do, and confidence in the process.

Documentation builds trust among your team and confidence among your stakeholders/coworkers. Use it to your advantage and you’ll see the benefits in the long term.

The best way to do this is in the README for the project, but also being able to communicate with the stakeholders about updates and status of infrastructure and other important information. Create a wiki or blog and update it (not just the first week you use it).

You should be transparent with the naming conventions for your team and outside contributors and the best practices you employ. Not just in the linting process, but the overall standards you set.

Don’t fix something twice

Let’s say you get tasked with checking why an application isn’t working properly and you figure out that there is an issue with a configuration file’s contents. Someone accidentally formatted a setting incorrectly and it can’t be parsed.

Once you identify the fix, at the very least you should write an InSpec profile so that you can be proactive and triage other issues quickly. Ideally, you’re using Chef or some other configuration management and can also make sure this never happens again. Write a Cookbook to resolve this.

Audit first using InSpec. If you trust your automation, apply the cookbook.