Support for Amazon EKS
See original GitHub issueI need to have support for Amazon EKS for my skuber use case. This requires, at some level, an integration with Amazon STS to retrieve a token for use in the RequestContext
. Off the top of my head, it looks like there are two broad (but orthogonal approaches):
- orchestrate this token retrieval outside skuber and just pass the token in via the current credentials interfaces
- add support to skuber for exchanging long-lived AWS credentials for a short-lived session token
The catch is that the retrieved tokens have an expiration. This can be specified at request time, but the maximum is only 36 hours. Either of these approaches will work for my skuber use case; I use ephemeral contexts, so that I don’t have to worry about the token expiring. However, I imagine many users will have long-lived contexts that may out-live the valid lifespan for the token. In this case, either:
- a new context needs to be generated (perhaps we can provide a factory for making this easier)
- the context needs a new token
This “replacement” could be done on demand or scheduled according to the lifespan of the token (the latter, requiring a scheduler; I was leaning towards doing this in a small actor system).
Naturally, all of this should be done so as to minimize external libraries, adhere to idiomatic Scala, and maintain backwards compatibility.
Before embarking on this work, I wanted to solicit opinions; no sense in writing code that will be rejected or useless for other use cases.
Summoning @doriordan
Issue Analytics
- State:
- Created 5 years ago
- Comments:25 (24 by maintainers)
Okay, I’ll do this. Unfortunately, I was time-boxed on this task, and I’ve used up all of my time. Hopefully I’ll be able to pick it back up in the next week or so. Otherwise, I’ve gone ahead and issued a pull request with my branch, so that anybody who wants to pick this up is able to. Please let me know if you do so that we do not duplicate effort; I’ll update this issue when I restart.
I think we need to bite the bullet and handle renewal on 401 responses. Doing this in a clean way needs a little thought - we would need the retry mechanism to basically wrap every method on the that results in a call to the Kubernetes API.
I think we can do this by wrapping the request invoker (https://github.com/doriordan/skuber/blob/7e10b3f6f0c2a7e96ec4d71eb66123ab0ff1e408/client/src/main/scala/skuber/api/package.scala#L821) in another invoker that gets passed to the RequestContext. This wrapping should only be done only in the case where the configured Auth Provider supports refreshing tokens on 401 responses. The wrapping invoker (lets call it TokenRefreshingInvoker) would check the response status and if it is a 401 it refreshes the token using the supplied auth provider and retries the request.