Details
-
Improvement
-
Resolution: Unresolved
-
Major
-
None
Description
At present the UI appears to generate a cookie which is very much tied to a specific node e.g.
Set-Cookie: ui-auth-192.168.99.100%3A31891=62a1e59f0b5105d1545ded63f7e52913; Version=1; Path=/; HttpOnly
|
I assume this is derived from the HTTP Host header give the setup I observed this from.
This is very anti cloud native however. By default Kubernetes will randomly load balance to any node based on fewest connections. Once we have an authentication cookie it's likely further requests will hit a different endpoints and fail the authentication redirecting back to the login path.
We cannot use IP based session affinity because AWS ELB doesn't support it. Even with the "local" routing policy it only manages to maintain sessions for a finite time before the browser closes the TCP session, so not a great user experience.
We also would rather avoid L7 ingresses as they are not generic across clouds, need user intervention, have different setup per provider. Add to this the setup to achieve TLS termination and re-establishment and what may not even be possible with a cookie based session due to the variable name and it's not a great solution.
What this proposes is to set an authentication cookie which identifies the user and is digitally signed using some method to prevent tampering. From this regardless of which server the request lands on it can be verified and the request processed with the RBAC permission granted to the user. The signature could be a salted hash (or HMAC) of the user name (the salt is secret and shared across the cluster), or with a more secure solution such as DSA. Either way, we'd probably need regular key rotation to prevent infinite impersonation if a token is exposed, or whatever you deem suitable.
Not a small ask but welcome to cloud computing
Attachments
Issue Links
- blocks
-
K8S-933 Openshift: Unable to login to the Couchbase UI with the AWS ELB service
- Closed
- links to