Kubify Talks to 1Password
Table of Contents
tl;dr
I added support to kubify to query 1Password for SSH key information. This allows kubify to SSH into Kubernetes nodes to install and upgrade versions.
Problem: I often delete and reinstall (one of) the Kubernetes cluster(s) in my homelab. I also sometimes reinstall my desktop machine, and start with fresh SSH credentials. Often those desktop SSH keys were the ones I would use to access the Kuberetes cluster. So how do I reinstall/upgrade the Kubernetes cluster machines without relying on the credentials of my desktop?
Solution
- Use a role user, whose SSH keys are stored in 1Password, to SSH into the Kubernetes machines.
- Store the role user’s SSH credentials in 1Password, and give kubify a way to access these credentials via the Python SDK.
- Add the SSH keys into the Python paramiko client instance, and use those credentials to access the Kubernetes nodes to perform management operations.
The initial changes were added in this first commit. This added two new configuration options:
onepassword_serviceaccount_key: authentication bits to allow programatic access to your 1Password vault.onepassword_item: 1Password item to query for SSH key information.
The second set of changes are an optimization over API access to 1Password. Why was this needed? 1Password has rate limiting on their service accounts. Depending on how many Kubernetes hosts there are to manage, there could be hundreds or thousands of API calls to retrieve the SSH private key for each kubify execution. My optimization queries 1Password once per kubify execution, and then uses those cached credentials for all further SSH operations.
The last few lines of a clean install show the elapsed time and number of API calls for 1Password:
2026-08-21 22:34:35,634 kubify.py:1101 INFO completed running kubernetes build. Elapsed Time 00h:07m:56s.
2026-08-21 22:34:35,634 kubify.py:1107 INFO 1Password API Calls Count: 1
2026-08-21 22:34:35,634 kubify.py:1108 INFO 1Password Cached Credentials Calls Count: 150
Things I don’t like
- The SSH keys are stored in memory of the Python process. If you have access to the machine running kubify, with some knowledge, you can access the process and retrieve the private keys. I’m sure there are ways to store these credentials more securely.
All of this is of course optional. Support still exists to use the SSH agent locally on the machine if that configuration suits your environment.