Chapter 4. Controlling Access to Resources

So you decided that you were going to set up a Chef server and configure your infrastructure in a smart way. Good for you! However, once you've moved past this stage, the next stage that will come and haunt most organizations is: How do we ensure that everyone is able to contribute towards using Chef, while ensuring that no big mess up happens when everyone is busy modifying the Chef code? Above all, how to ensure that anybody who is not supposed to access resources on the Chef server is denied access?

Chef provides a very fine-grained, role-based access to resources through Enterprise Chef.

Any system that has to provide for such a mechanism has to have two components included in it:

• Authentication

• Authorization

All communication with the Chef server is through the Chef Server API. The API provided by Chef is a REST API, and the access to the API is restricted using authentication mechanisms. Public key encryption is used in both Enterprise and Open...

The bootstrap process

Before we jump into understanding the authentication and authorization mechanisms available in the Chef ecosystem, let's look at the bootstrap process used for the purpose of bootstrapping a new machine using Chef. There are two ways to bootstrap a new node:

• Using the knife bootstrap subcommand

• Using a custom orchestrator, which can bootstrap a new machine

In both the cases, unless you are using the chef-client version 12.1 (or higher) and the validator-less bootstrap, you'll require the validator's private key for the first chef-client run on the node. If you are using the Open Source Chef server, this key can be found in /etc/chef-server/chef-validator.pem, whereas, for the Enterprise Chef server, this key will be issued to you during the initial setup.

If you are going to use the knife bootstrap subcommand, this key should be copied over to the machine from where the knife bootstrap subcommand will be invoked. Also, update your knife.rb file on the workstation with the...

Authentication

Communication with the Chef server can be initiated by different mechanisms such as chef-client, Knife, and using API in code. Let's see how authentication works under different circumstances.

chef-client

Every time a chef-client needs to communicate with the Chef server to fetch some data required for bootstrapping a machine, the chef-client needs to authenticate itself with the Chef server. It does so by using a private key located at /etc/chef/client.pem. However, as we saw in the bootstrap process, when a chef-client is executed for the very first time, there is no private key on the concerned machine. Hence, a chef-client makes use of the private key assigned to the chef-validator (/etc/chef/validation.pem). Once the initial request is authenticated, a chef-client will register with the Chef server using validation.pem, and subsequently the Chef server will return back a new private key to use for future communication. Once the initial chef-client run is over, validation...

Authorization

As we discussed earlier, users of Chef can only perform actions that they are authorized to perform. There is a difference in the implementation of authorization between the Enterprise and Open Source Chef server.

The Enterprise Chef server makes use of the role-based access control model.

The Open Source Chef server, on other hand, has a fairly simple model, where there are either admin users who have the privilege to read, write, update, and delete resources, or non-admin users who have read-only access to resources on the Chef server.

Let's look at each of these in detail.

The Open Source Chef server

As we discussed earlier, the Open Source Chef server has a very simple model for authorization purpose. We've two sets of users: admin and non-admin. Any user with an admin privilege can read, write, update, or delete any resources on the Chef server, whereas non-admin users have read-only access to the resources on the Chef server.

When a node is registered with the Chef server through...

Summary

In this chapter, we went on to understand how authentication happens in the Chef server and how one can make use of custom APIs to connect securely with the Chef server. We also saw different models of authorization used by the Enterprise and Open Source Chef server. I hope by now you know how authentication and authorization happen in the world of Chef and how you can choose the right variant of the Chef server for your use, depending on your requirement s with regard to the granularity of authorization levels needed.

In the next chapter, we'll learn about the most fundamental unit of code written by Chef developers: is a recipe. Components of a recipe and its resources (among other things) will be covered next.