As much as we love the Internet, it’s common practice to limit the amount of exposure our servers have to it. Limiting ingress to your production and non-production environments via firewalls won’t affect the functionality of your Chef deployment, but locking down egress can cause some difficulties.
Installing Chef Client Without Internet Access
You can download Chef software from https://www.chef.io/downloads and via https://www.getchef.com/chef/install.sh. However, if all of your hosts are unable to request urls from the Internet, you have some options on how to get chef-client installed in your environments.
Add the chef-client package to your images
Adding the chef-client package to the images that build your infrastructure is definitely an option if you can regenerate those images easily.
You can choose how much Chef-related material to ship in your images. It’s possible to pre-populate system images with not just the chef-client software, but also the organization validator key and a client.rb file to maintain uniformity across all newly instantiated systems. This works well if your systems will all belong to a single organization.
Add chef-client to your post-install scripts
Slightly downstream from pre-populating the image with chef-client is adding chef-client to the post-install scripts of your imaging system. In tools like Kickstart, you can use the %post directive to install chef-client and procure the organization validator keys from a secure location. This approach means that you won’t have to build a new operating system base image for every Chef organization your nodes belong to.
In either of these two scenarios, you’ll want to keep the images and organization keys securely stored. The validator key in particular has special rights to create new nodes on the Chef server, and should be protected. The chef-client cookbook includes a recipe to delete the validator key from nodes after they join their organization.
Customize your bootstrap options
Another low-friction mechanism for installing chef-client on your nodes is to customize your bootstrap options so the packages are sourced from your repositories.
The knife bootstrap subcommand has a couple of options that allow you to substitute local operations in place of the default https://www.getchef.com/chef/install.sh command.
In a homogeneous environment, using knife_bootstrap_command in your knife.rb allows you to specify a single new command to replace install.sh:
[code]knife[:bootstrap_install_command] = ‘yum install –y chef-client'[/code]
This configuration option overrides the install command for all cases of knife bootstrap.
If you have multiple target operating systems in your environment, you may want to use the template or distro option.
The distro and template options are similar to each other, but the template option allows you to specify an arbitrary path for the file you’ll create. The distro option has a limited set of paths that it searches.
The content of the template files can be fairly simple. A template need only contain the command to acquire and install the chef-client software, and create the client.rb and validator.pem files. On the other hand, the template can be more complex if you support platforms that don’t yet have chef-client omnibus packages.
The chef-client and Chef DK packages include a number of sample bootstrap templates. Some other samples are also in the chef github repo.
All of these templates have a number of shortcuts for creating the /etc/chef/ directory, copying the validator.pem file, creating the client.rb file, and copying any secrets you might use for encrypted databags.
There is no limit to how many custom templates you can use with knife bootstrap. For example, you can create one custom template for your rpm-based systems, a second for your apt systems, and a third for your Windows systems.
Bootstrapping Windows systems is slightly different from bootstrapping Linux and UNIX systems, but the bootstrap script included with knife windows is a good place to start.
The url value in the template is what you’ll want to replace with the download url that works for your environment.
Chef Environment Lifecycle
In order to maintain an environment secluded from the rest of the Internet, you’ll likely use a number of local repositories to keep your systems up to date. Chef is just one more component in that maintenance cycle.
Chef will soon provide public repositories that can be mirrored to your repos. We’ll have more information soon on how to make use of these repos, hosted by our friends at PackageCloud. You can then keep your clients as up to date as your site guidelines recommend. The omnibus updater cookbook is one option for keeping your clients updated.
Some useful add-ons to Chef, like chef-vault require that you install additional Ruby gems on your systems. For environments that are partitioned from the Internet, there are several options for mirroring and maintaining an on-premise gem server, including Gem in a Box, at http://guides.rubygems.org/run-your-own-gem-server/
Finally, the yum and apt cookbooks provide lightweight resources and providers (LWRPs) for making repository configuration management easier on your client nodes.
Getting Updates
Chef server, chef-client and Chef DK all use a lot of different open source software components, so we recommend having a regular update schedule for the components you are using. Watch our blog for bug reports, feature enhancements, and updates that might affect your infrastructure.