|
OverviewThis page provides an overview of the identity through which requests to the Chef server are authenticated through the Server API, how the clients become registered with a valid identity, and how the API clients can be managed. See Authentication and Authorization for details on the authentication and validation process itself.Authentication IdentityIn chef, node data is separate from the identity used to authenticate requests to the Chef server, which is managed by an API client. Each API client has a public/private key pair. The public half of the key is stored in the database on the server, and the private half is kept locally by the client.
Each request to the Chef server includes a request signature in the HTTP headers. The request signature is computed from the hash of the request content and encrypted with the client's private key to verify the identity of the user or machine making the request and prevent attempts to tamper with the content. |
|
Client RegistrationWhen a node runs chef-client for the first time, it generally does not yet have an API client identity, and so cannot make authenticated requests to the server. This is where the validation client—named "chef-validator" by default comes in.
Once the client machine has registered itself with the chef server, it no longer uses the validation client for anything. It is recommended that you delete the validation client's private key from the host after the host has registered. API clients can be managed with Knife, the Server API or the Management Console. Managing API Clients With KnifeKnife is Chef's powerful command line tool, and can be used to create, edit, view, list, and delete API clients. Details on this use are at Managing API Clients With Knife. Managing API Clients through the Management Console
Managing API Clients through the Server APIPlease refer to the Server API article for information about managing API clients through the REST API.
|
|
|


