Okay! Now that I have an instance of Vault next up is to figure out how to bootstrap it via a script. Afterwards I hope to have time to begin exploring the implementation behaviors. First up is tearing out my resources. In one example is saw I might be able to do it using kubectl delete -f reosurce.yml. Well that worked better than I was hoping for!

There are now two scripts I use: setup.sh and teardown.sh. A few seconds after I run setup.sh I have a Vault instance up, running, and unlocked. A few seconds after teardown.sh the resources are gone. I consolidated the secure resources like the ServiceAccount, Role, and RoleBinding into a single file named security.yml. The Vault definition has a lot of details and felt outside of the scope. With this new automated construct I can test the security rules on launch.

Restricting Secrets

My current configuration allows for access to all secrets. I would really like to restrict the secrets to just the unseal token instead of giving it everything. Of course the following change did not work the way I was hoping.

 - apiGroups: [""]
   resources: ["secrets"]
+  resourceNames: ["vault-unseal-keys"]
   verbs: ["*"]

With variations on this I was not able to figure out why the resource names or the sub-resource specifications secrets/vault-unseal-keys were not properly allowing the secrets to be read or written. Going to the source I crawled through several levels. The authorization layer is interestingly pluggable, which makes sense given the references to 1.6 having both a ABAC and RBAC layers available.

At the core a request is translated into a type ResourceAttributes struct which will be applied against type PolicyRule struct within RuleAllows. This is attached via the configuration module’s func New when the Config object contains RBAC for the AuthorizationModes. This places the RBACAuthorizer.Authorize into the resulting path.

Although I have learned quiet a bit about the internals of the authorization system I was not able to figure out why the secrets are treated differently or even how. Unsurprisingly the Kubernetes code base is large with many layers of abstraction. I have ventured as far off the path as I had time boxed. I am sure I will return to this type of problem in the future, I just hope the other resources work with the RBAC layer as documented.