Opening this up as a draft while I further validate the change.
The purpose of this change is to support defining k8s secrets as a direct source for bearer token credentials.
To support this, much as with the tunnel group configmap source, a k8s:// scheme prefixed path is given.
This can be put in either of then tokenPath or hashedTokenPath slots in the authentication section of a tunnel group yaml configuration file.
The protocol for the new path syntax is k8s://secret/[namespace]/[name]/[key].
For example, the following tunnel groups configuration yaml configures a group with a k8s secret source for credentials.
The secret is named credentials and is located in the default namespace. The token is pre-hashed (SHA256) and stored hexidecimally encoded in the key token.
[x] Initiate secret source informer once per namespace (avoid starting too many watchers)
It now relies on the shared factory to handle shared caching. I am unsure if starting multiple informers via a shared factory in this way will ensure the informers are cached. So may need to revisit this in the future. We will see.
[x] Explore testing options
Added the fake clientset to do some unit testing. This helped find some bugs.
Opening this up as a draft while I further validate the change.
The purpose of this change is to support defining k8s secrets as a direct source for bearer token credentials. To support this, much as with the tunnel group configmap source, a
k8s://
scheme prefixed path is given. This can be put in either of thentokenPath
orhashedTokenPath
slots in the authentication section of a tunnel group yaml configuration file.The protocol for the new path syntax is
k8s://secret/[namespace]/[name]/[key]
.For example, the following tunnel groups configuration yaml configures a group with a k8s secret source for credentials. The secret is named
credentials
and is located in thedefault
namespace. The token is pre-hashed (SHA256) and stored hexidecimally encoded in the keytoken
.TODO:
It now relies on the shared factory to handle shared caching. I am unsure if starting multiple informers via a shared factory in this way will ensure the informers are cached. So may need to revisit this in the future. We will see.
Added the fake clientset to do some unit testing. This helped find some bugs.