Use relative paths in Kubernetes config
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Relative paths can work in Kubernetes-related config, but only in places where the consuming tool actually reads files from the local filesystem. The most common valid case is kubeconfig, where file references such as certificates and keys can be relative to the kubeconfig file itself.
Relative Paths in kubeconfig
A kubeconfig file can reference local certificate and key files with fields such as:
- '
certificate-authority' - '
client-certificate' - '
client-key'
Example:
In practice, those relative paths are resolved relative to the kubeconfig file location, not relative to whatever shell directory you happened to be in when you ran kubectl.
That makes a checked-in directory layout portable, which is usually the main reason people want relative paths in the first place.
Why This Is Useful
Using relative paths in kubeconfig helps when you keep a config bundle together:
- one kubeconfig file
- one
certsdirectory - optional helper scripts nearby
That structure is easier to move between machines and easier to keep under version control, assuming the certificates themselves are handled appropriately.
A layout like this is common:
Then commands such as the following work naturally:
Do Not Generalize This to Every Kubernetes YAML Field
A common misunderstanding is assuming that any file-looking path in Kubernetes YAML can be relative in the same way. That is not generally true.
For example:
- a Pod manifest does not read local machine files at apply time just because you wrote a relative path in some random field
- volume mounts refer to paths inside containers or nodes, not paths relative to the manifest file
- most resource specs describe cluster state, not local file inclusion
So the safe rule is: relative paths are meaningful only where the specific tool explicitly supports local file references.
Kustomize Is a Different Case
Kustomize also uses relative paths heavily, but that is a Kustomize feature, not a generic Kubernetes API behavior. In kustomization.yaml, entries such as resources, patches, and generators are commonly relative to the kustomization file.
Example:
This is valid because Kustomize is building manifests from local files before talking to the cluster.
So if someone says "relative paths work in Kubernetes config", they may actually mean either:
- kubeconfig path references
- Kustomize file references
Those are not the same thing, and mixing them up leads to confusion.
Prefer Embedded Data When Portability Matters Most
For kubeconfig files, another option is embedding certificate data directly as base64-encoded fields such as certificate-authority-data and client-certificate-data. That avoids path resolution entirely.
Relative paths are nice when you want readable local bundles. Embedded data is nice when you want a single self-contained kubeconfig file.
Choose based on how the config is distributed and maintained.
Common Pitfalls
- Assuming all Kubernetes YAML supports relative local file paths in the same way kubeconfig does.
- Forgetting that kubeconfig paths are resolved relative to the kubeconfig file, not the current shell directory.
- Confusing kubeconfig behavior with Kustomize behavior.
- Using relative paths for secret material without thinking about how the directory is distributed and secured.
- Expecting Pod manifest fields such as container paths or mount paths to behave like local file references.
Summary
- Relative paths are commonly valid in kubeconfig for certificate and key file references.
- Those paths are resolved relative to the kubeconfig file location.
- Kustomize also supports relative paths, but that is a build-time tool feature.
- Most ordinary Kubernetes resource fields do not interpret local relative file paths.
- Use the tool-specific path model that actually applies instead of assuming all YAML fields behave the same way.

