Sometimes, you can run into a situation where you need to include a resource that lives in a place you had previously gitignored for safety reasons. One such example I ran into yesterday was kubeconfigs resulting from our eksctl usage. While we don’t want the root kubeconfig to accidentally get committed, we do want certain user kubeconfigs, in this case admin configs, to get stored in the same repo.

We can do this as we use aws-iam-authenticator with roles to grant users privileges. These then map to a respective user in Kubernetes.

First, here’s the rough structure of our infra repo:

* `<prettyname>-<environment>` - directory holding all cluster assets (i.e. `dev-sandbox`)
  * `eksctl.yaml` - eksctl configuration file
  * `reckoner.yaml` - reckoner configuration file
* `shared` - Collection of shared configurations (i.e. yaml that isn't specific to any one given environment)
* `kubeconfigs-admin` - Admin Kubeconfigs for all clusters, enabled for our team members.

And here’s how I enabled kubeconfigs-admin to hold kubeconfig* type files:

## Allows for admin kubeconfigs, but thats all in subdirs
## Here to protect from root kubeconfigs being checked in
## This was fun: https://stackoverflow.com/a/18702826
clusters/**/kubeconfig*
!clusters/kubeconfigs-admin/
!clusters/kubeconfigs-admin/**

So now we can store a file named kubeconfig-dev-sandbox-admin and ensure it will be available for committing into our repo! See here for more info and examples.

Mario Loria is a builder of diverse infrastructure with modern workloads on both bare-metal and cloud platforms. He's traversed roles in system administration, network engineering, and DevOps. You can learn more about him here.