Learn Chef - Authentication & Security

#Introduction

In episode 12 you connected nodes to Chef Automate and saw compliance reports in a single dashboard. All of that data travels over the network — and networks are never secure by themselves. In episode 13 we focus on the layer that protects the entire ecosystem: authentication & security. From client key validation and SSL certificates to storing secrets with encrypted data bags and chef-vault.

The goals of this episode:

Understand how the Infra Server validates clients.
Set up secure workstation-server-node communication.
Encrypt data bags.
Use chef-vault for multi-node secrets.

#Client Keys and Validation

Every node registered on the Infra Server has a unique client object. During bootstrap, chef-client generates a new key: the private key is stored on the node, while the public key is registered on the server. On every subsequent connection, chef-client signs requests with its private key and the server verifies them against the public key of the client object. That is why moving a private key from one node to another is a serious violation.

client.rb — key location

chef_server_url "https://chef.example.com/organizations/devops"
client_key "/etc/chef/client.pem"
node_name "app-01"
validation_client_name "devops-validator"

Warning

Never use another node's private key, including devops-validator, which is only used during bootstrap. After bootstrap completes, remove the validator key from the node so it cannot be used to infiltrate the server.

#SSL Certificates and Trust

On first installation, the Infra Server generates a self-signed certificate. The workstation and nodes must trust this certificate so HTTPS connections run without warnings.

Check and fetch the server certificate

knife ssl check -c ~/.chef/knife.rb
knife ssl fetch -c ~/.chef/knife.rb

To make sure trust is configured correctly, knife ssl check gives a direct verdict. knife ssl fetch stores the server certificate in ~/.chef/trusted_certs/. Nodes do the same during bootstrap — the certificate is stored in /etc/chef/trusted_certs/. Outside a learning environment, use a public or internal CA so all parties trust the same certificate chain.

Communication layer	Credentials	Direction
Workstation to server	Admin client key + server cert	knife, berks
Node to server	Node client key + server cert	chef-client run
Server to node	Server cert + authorized key	chef-push, scan

#Encrypting Data Bags

A regular data bag item can be read by anyone with access to the server. For sensitive data, use encrypted data bags: the item is encrypted with a secret key that only you keep.

Create an encrypted data bag

mkdir -p data_bags/secrets
knife data bag create secrets db_password --secret-file ~/.chef/secret_key

Example item:

data_bags/secrets/db_password.json

{
  "id": "db_password",
  "password": "P@ssw0rdRahasia"
}

Read it back in a recipe by supplying the secret:

Reading an encrypted data bag

secret = Chef::EncryptedDataBagItem.load_secret("/etc/chef/secret_key")
db = data_bag_item("secrets", "db_password", secret)
template "/etc/app/db.conf" do
  variables password: db["password"]
end

Important

The secret key that encrypts a data bag is the last line of defense. Store it in a password manager or Vault, never commit it to git, and rotate it together with the data bag whenever a team member leaves.

#chef-vault for Multi-Node Secrets

Encrypted data bags are good, but the secret is the same for every node that can read it. chef-vault solves this problem: the item is encrypted with the public key of specific clients, so only allowed nodes can unlock the secret.

Create and set chef-vault access

knife vault create secrets db_password '{"password":"Rahasia123"}' \
  -M client -S "role:app-server"
knife vault refresh secrets db_password

Reading it in a recipe:

Reading a chef-vault item

require "chef-vault"
vault_item = chef_vault_item("secrets", "db_password")
template "/etc/app/db.conf" do
  variables password: vault_item["password"]
end

Make sure the cookbook declares the chef-vault dependency in metadata.rb so the library is available at runtime.

Comparison of secret storage approaches:

Method	Security	When to use
Cookbook attribute	Low	Almost never
Regular data bag	Low	Non-sensitive data
Encrypted data bag	Medium	Shared team secrets
chef-vault	High	Secrets per role or node

#Secret Best Practices

Never store secrets in cookbooks, attributes, or templates.
Limit who can read data bag and vault items.
Rotate secrets and keys regularly.
Audit access and integrate with Automate to see who changed what.

#Conclusion

In this episode 13 you understood the security of the Chef ecosystem: a unique client key per node validated by the Infra Server, SSL certificates secured via knife ssl fetch, encrypted data bags for shared secrets, and chef-vault for multi-node secrets.

Key takeaways:

Unique client key per node — moving a key is a security incident.
SSL trust — workstations and nodes must trust the server certificate.
Encrypted data bag — encrypt items with a tightly guarded secret.
chef-vault — per-client encryption with public keys.
Never store secrets in cookbooks — always put them in a vault or an encrypted data bag.

In the next episode, episode 14, we bring everything we have built to the cloud: Cloud & IaC Integration — managing AWS, GCP, and Azure instances, integrating Terraform and cloud-init, and the patterns of automated bootstrap and golden images. See you in episode 14!