k8s features pluggable authentication, but includes 5 strategies in the order of attempted application:
K8s.Conn.Auth.Certificatecertificate based authentication
K8s.Conn.Auth.Tokentoken based authentication
K8s.Conn.Auth.AuthProviderimplements a Kubernetes config file's
K8s.Conn.Auth.Execimplements a Kubernetes config file's
K8s.Conn.Auth.BasicAuthusername/password basic auth
A few notes first:
K8s.Conn.Auth.AuthProvideris itself an authentication strategy that allow shell calls to provide a Bearer Token. It's unfortunately named, but the names of the modules follow the key names in a Kubernetes config file. More on this strategy can be found here.
K8s.Connstruct encapsulates a connection to a cluster. It has the cluster address as well as how to authenticate to the cluster.
K8s.Connstructs can be constructed manually, but there are a few helpers here to create one.
K8s.Conn.Auth.Tokenauth strategy is probably the simplest strategy to review as a reference implementation.
Two things are required to implement a custom auth strategy:
Implement the K8s.Conn.RequestOptions protocol which should create a
RequestOptionsstruct. This struct is used to set HTTP Headers and SSL connection options.
Looking at the Token example:
- Line 13 implements the case where this auth strategy would be able to generate request options
- Line 14 implements the default case where it cannot authenticate the request
- Lines 19-24 implement how to generate HTTP Headers and SSL options to be used by HTTPoison to make the HTTP requests.
Authentication providers are traversed in order. The first provider to return an
K8s.Conn.Auth struct is used. Default providers are checked after any providers supplied to in the Mix config key
config :k8s, auth_providers: [CustomProvider1, CustomProvider2]
This would result in authentication attemps in the following order:
For protocol and behavior implementation examples check out