Chef Server, Nodes, and Workstations

When using Chef to manage your infrastructure, you will be dealing with three types of hosts: a Chef Server, Nodes, and Chef Workstations.

Chef Server

The Chef Server is the central store of your infrastructure's configuration data. The Chef Server stores the data necessary to configure your nodes and provides search, a powerful tool that allows you to dynamically drive node configuration based on data. A REST API makes this data accessible to nodes and chef workstations. Optionally, you can use the Chef Server's WebUI to manage your infrastructure via a web interface. Hosted Chef users have a hosted Chef Server, managed as a service by Opscode with a WebUI interface that is accessible at http://manage.opscode.com.

Nodes

A Node is any host that is configured using chef-client. Chef-client runs on your nodes, contacting the Chef Server for the information necessary to configure the node. From the point of view of the Chef Server, a node is little more than a run list, the list of recipes and roles that will be applied to the node and define its configuration, and attributes, a set of data about the node itself. Since a Node is a machine that runs the chef-client software, nodes are sometimes be referred to as "clients". (This is separate from API clients, that are authenticating against the Chef-Server API.)

When nodes are referenced as "clients", it implies the link between the chef-client executable, the API call made for authentication and authorization using the identity information in the API client object, to save the node object on the server.

Chef Workstations

A Chef Workstation is the host you use to modify your cookbooks and other configuration data--typically the local workstation of a system administrator. Such a workstation has two key components:

1. the knife executable shipped with chef and
2. a repository containing your infrastructure's configuration documents.

As we will see, these configuration documents include cookbooks, data bags, roles, and more. Ideally, these configuration documents are managed by a version control system. Using knife, your workstation is used to upload configuration data to the Chef Server as well as communicate with individual nodes over SSH when necessary.

Clients, Authentication, and Authorization

Chef uses API Clients and a system of authentication and authorization to ensure that your configuration data is only read and updated by those authorized to do so. Chef-client (running on nodes) and knife (running on workstations) communicate with the Chef Server using API clients.

In other words, Chef Client is the 'chef-client' software executable itself. An API Client is the object that represents the cryptographic identity used for authentication and authorization in every API call.

To ensure that requests are coming from known API clients, Chef uses public key encryption, with Hosted Chef users having some additional fine-grained controls. API clients have associated private and public encryption keys. Every API request made by chef-executable is signed with a specific API client's private key. The Chef Server then verifies that the request is authentic with the client's public key.

Once the Chef-Server verifies that the request is authentic, it then ensures that the client making the request, has permission to take whatever action they are requesting (such as uploading a cookbook or retrieving a run_list). This process is known as authorization. Open source Chef Server and Hosted Chef use different authorization systems.

Open Source Chef

In Open Source Chef, certain API clients can be marked as "admin clients." Authorization for various actions is determined by whether the API clients is marked as an admin or not. Admin clients are used when making requests via knife and have all possible permissions. Non-admin clients have limited permissions and are used for nodes within your infrastructure.

Hosted Chef

Hosted Chef uses a more complex authorization system that provides fine-grained control on a client-by-client (or user-by-user) basis. In this system, API clients and users can have CREATE, READ, UPDATE, DELETE, or GRANT permission on the objects stored on Hosted Chef (node data, cookbook data, etc). Hosted Chef ensures that the requesting client has the appropriate permission for the requested action. In order to make managing permissions easy, Hosted Chef provides a number of pre-made groups that have permissions appropriate for different roles. Users and Clients that are members of the "admin" group have all permissions on all objects. Non-human API clients (such as those used by nodes) will automatically be placed in the client's group, which has permissions similar to non-admin clients in Open Source Chef, while human users can be placed in the "users" group, which has permissions similars to admin clients in Open Source Chef. For more details see Hosted Chef Authorization.

When chef-client runs on new nodes, Chef is designed to automatically create a new API client for the given node. Because of this, once your users or admin clients are set up properly to use knife and log into the WebUI or Management Console, there is often little need to think about the specifics of API clients, authentication, or authorization.

Hosted Chef

In addition to the more fine-grained authorization system, Hosted Chef has two concepts not used in Open Source Chef: Users and Organizations.

Users

Users are what you think they are: credentialed entities used by humans to connect to Hosted Chef. Like clients, they have keys that they can use to connect to Hosted Chef programmatically, via api.opscode.com or knife. But they also have passwords that they can use to log in to the various web pages that Hosted Chef exposes.

Users can be associated with an organization, which gives them certain rights to interact with and manage that organization. However, unlike API clients, Users can be associated with more than one organization, for example a consultant could create a separate organization for each of his customers. When thinking about authentication and authorization issues, it is easiest to think about a user as just another API client.

Users have single accounts across all the Opscode web pages. The same username and password can be used to log in to Hosted Chef Management Console, the Opscode Cookbooks Site, or help.opscode.com.

Organizations

When you sign up for Hosted Chef, you create a user account and an organization. Your organization may represent your entire company, or the department you work in, or any other grouped set of server infrastructure you plan on managing. Organizations are the things that get billed for use of Hosted Chef. With the exception of users, nothing is shared between organizations. An API client in one organization cannot read node data from another organization. When using Hosted Chef, it is as if each organization has its own, private chef server, managed by Opscode.

Summary

• The Chef Server is the central store of configuration information.
• Nodes and Workstations communicate with the Chef Server using API Clients that make requests to a REST API.
• All API requests are checked for authenticity and authorization.

Chef Basics

Core Components