and this goes into the /etc/kubernetes/manifests/kube-apiserver.yaml file if you’re a Kubeadm user. Easy enough, right? So, you just need the secrets.conf config, which just contains your encryption key (which you’ll rotate periodically, and I’ll cover that in a moment), and the provider for secrets encryption (these are built-in, but there are options for if you use a KMS, or your cloud provider offers an option that can be integrated with the Secrets API for this purpose–AWS Secrets Manager, for example, if you’re an EKS user), so you need a file like this:

which, again, seems straightforward enough, however, if your cluster spin-up routine has a high level of automation, and has integration with a config management suite, or provisioning tools like cloud-init and Terraform, you might not want to stop to configure this manually, and adding this to your spin-up routine is a consideration worth making.
In my case, I have a Terraform project that spins up and configures, via cloud-init, my cluster after the servers and network resources come online, and in this routine, if a user defines a variable like secrets_encryption to be true, a function like this runs:

and outputs this new configuration to /etc/kubernetes/secrets.conf on my cluster controller, for my kube-apiserver binary to pickup when the additional option described above is defined. In my case, my project uses Kubeadm, so I also need a function like:

to mount the config we just generated to a volume the container running the apiserver will be able to read from, and then add the new option.
Using most other deployment methods, you might have a systemd service managing your API server, that can be modified like any other service and then run systemctl daemon-reload and restart the service to pick up the change. This would be a good candidate for something automated on cluster spin-up.
If you, down the road, need to rotate this encryption key, the process is something like:
Add a new entry to your /etc/kubernetes/secrets.conf:

ensuring that the new key is the first in your list, preceding the old key. If you’re a Kubeadm user, you’ll need to open the kube-apiserver.yaml file to restart the apiserver process, otherwise, this will just require restarting the apiserver service.

Refresh your secrets to use the new key for encryption:

kubectl get secrets -o json | kubectl replace -f -

Remove the old entry, and restart the apiserver again.
Planning automation for a task like this is a little more involved than generating the configuration in the first place, or is one of few tasks you might write into a separate set of playbooks from your cluster spin-up work (i.e. you might run this via Ansible, or whatever your team uses for host management) that might not require rolling the entire cluster to bring up-to-date.