No way to provide Keystone credentials via config to kubernetes-master for k8s-keystone-auth

[Dmitrii Shcherbakov]

There is currently a requirement to have a relation between charm-keystone and charm-kubernetes-master.
https://ubuntu.com/kubernetes/docs/ldap
https://github.com/charmed-kubernetes/charm-kubernetes-master/blob/master/reactive/kubernetes_master.py#L969-L979

This assumes that Keystone is deployed in the same model with K8s. Alternatively, if Kubernetes is deployed on top of OpenStack, the need for a relation imposes network connectivity requirements between a Kubernetes Juju controller and an underlying OpenStack Juju controller - in some environments this cannot be done for various reasons (e.g. customer policy).

With charm-openstack-integrator there is a way to use Keystone credentials either from config or via Juju trust. However, those credentials cannot be exposed in a manner usable by kubernetes-master:keystone-credentials endpoint.

It would make sense to have a way to use credentials obtained from openstack-integrator to also configure k8s-keystone-auth which would allow a Kubernetes deployment to avoid using a CMR relation to a controller of the underlying cloud.

[Tim Van Steenburgh (tvansteenburgh)]

https://github.com/charmed-kubernetes/charm-kubernetes-master/pull/91

[Cory Johns (johnsca)]

Dmitrii, I'd just like clarification on the network restriction issue. Is it the case that the policy disallows the two Juju controllers to talk to each other, thus preventing CMR, but does allow both the openstack-integrator and kubernetes-worker units to talk directly to Keystone?

[Dmitrii Shcherbakov (dmitriis)]

Cory, yes, that's correct. Keystone typically has a public API accessible from instances which is not the same for the underlying Juju controller.

[Cory Johns (johnsca)]

Previous PR superseded by:

https://github.com/juju-solutions/charm-openstack-integrator/pull/38

https://github.com/charmed-kubernetes/charm-kubernetes-master/pull/127

[Cory Johns (johnsca)]

The keystone-credentials interface layer will also need to be backported for this change: https://review.opendev.org/#/c/747970/