-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request juju#17606 from kian99/fix-federated-auth-with-deb…
…ug-logs juju#17606 This PR fixes an issue that prevented CLI users interacting with JAAS from running `juju debug-log`. When running `juju debug-log` against a model that is hosted on a controller connected to JAAS, the operation hangs and nothing is returned. This is because JAAS proxies all client requests and did not implement the models `/log` endpoint. It also however has no way of authenticating the user. Running `juju debug-log` does the following: 1. Connects to the Juju controller at `/model/<uuid>/api` creating an API client in the normal fashion, establishing a websocket connection and performing a login request. 2. It then goes on to establish a new separate connection to the `/model/<uuid>/log` endpoint, eventually establishing a websocket but instead of sending an RPC login request, it uses the apiClient's `ConnectStream` method where an HTTP basic auth header is sent that includes the user's password and includes the macaroons as cookies. 3. Proceeds to read from the websocket to stream logs. With JAAS' introduction of login providers and particularly the session login provider, it was realised that there is no mechanism in place to send the session token used with OIDC login in the basic auth header used in the `ConnectStream` method. Because JAAS acts as a proxy layer for all controller and model level calls, JAAS has no way of authenticating requests to `/model/<uuid>/log`. To fix this I have made the following changes in this PR. 1. ~~Add a `Token` method to the LoginProvider interface that returns a string. The string represents the token used for login.~~ After some discussion, this was changed to shift more logic into the login provider. Instead of returning a token that was then used as part of an HTTP header, the login provider interface now has an `AuthHeader` method that will return an HTTP header that can be used in places like the stream connector. 2. Added a `loginProvider` field to the `state` struct to keep the provider around, depending on how this is implemented, it's necessary to hold onto the provider because certain providers like the sessionTokenLoginProvider only obtain a login token after completing login. 3. I've replaced the logic in the `connectStream` method to use the login providers token rather than just the password from the state. A benefit of this is that it further reduces the use of `state.password` ~~which could probably be removed with some further refactoring.~~ and now it completely removes the need for storing `tag`, `password`, `nonce`, and `macaroon` on the state struct since they are nicely contained within the login provider. ## Checklist <!-- If an item is not applicable, use `~strikethrough~`. --> - [x] Code style: imports ordered, good names, simple structure, etc - [x] Comments saying why design decisions were made - [x] Go unit tests, with comments saying what you're testing - [ ] [Integration tests](https://github.com/juju/juju/tree/main/tests), with comments saying what you're testing - [ ] [doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages ## QA steps - `make install` - `juju bootstrap localhost test` - `juju add-model test` - `juju debug-log`
- Loading branch information
Showing
14 changed files
with
372 additions
and
153 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.