feat: Add cluster opt for host client basic auth #182
Merged
Conversation
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
Callisto13
force-pushed
the
basic-auth
branch
6 times, most recently
from
8acaa03
to
1e18e85
Compare
richardcase
reviewed
Jun 21, 2022
richardcase
reviewed
Jun 27, 2022
Callisto13
force-pushed
the
basic-auth
branch
2 times, most recently
from
cb6d9e9
to
d00ad76
Compare
**User value:**
This commit will let users set the basic auth tokens for each flintlock
host.
To keep things simple, users will create a secret in the same namespace
as their cluster. The secret can be called whatever they like, and they
provide the name of this secret in the `MvmCluster.Spec`:
```
spec:
placement:
staticPool:
basicAuthSecret: mybasicsecret
hosts:
- controlplaneAllowed: true
endpoint: 192.168.0.31:9090
```
The option is under the `placement.staticPool`, since it will only be in
the non-dynamic placement that users will know the endpoint address
ahead of time. How auth is handled in the dynamic scheduling case is
coming soon.
The host endpoint is relevant because that is what the controller will
use to look up the associated auth token in the secret. Users will
provide a map of the auth info in the secret data:
```
apiVersion: v1
kind: Secret
metadata:
name: mybasicsecret
namespace: default
type: Opaque
data:
192.168.0.31: Zm9v # foo, in this case
```
**Implementation:**
- In the secret example, note the absence of the `:` + port which would
make the secret invalid.
In the implementation, we remove the `:port` from the `endpoint`. To
stop doing this, we could split the `endpoint` into `address` and
`port`, and then gather those together for the `failureDomain`.
- I have refactored the flintlock client factory func to receive a
variadic array of opts that we build into a config. This just makes it
nicer to add more options to the client, without having to expand the
signature.
- I have not done any TLS here deliberately to keep the change small.
- The client simply adds the token to the request authorization header.
**Testing:**
- I have manually tested using Tilt + a local flintlock.
- Unit testing is interesting, since there are not any outcomes that I
can look for, since all the changes are on the client, which we use
fakes for anyway. I will continue to think on it.
richardcase
approved these changes
Jun 28, 2022
| token := string(tokenSecret.Data[host]) | ||
|
|
||
| if token == "" { | ||
| m.V(2).Info( //nolint:gomnd // this magic number is fine |
There was a problem hiding this comment.
I'd actually take off the verbosity of 2.
Suggested change
| m.V(2).Info( //nolint:gomnd // this magic number is fine | |
| m.Info( |
There was a problem hiding this comment.
eh i'll do that in the next one 😈
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of liquidmetal-dev/flintlock#356
User value:
This commit will let users set the basic auth tokens for each flintlock
host.
To keep things simple, users will create a secret in the same namespace
as their cluster. The secret can be called whatever they like, and they
provide the name of this secret in the
MvmCluster.Spec:The option is under the
placement.staticPool, since it will only be inthe non-dynamic placement that users will know the endpoint address
ahead of time. How auth is handled in the dynamic scheduling case is
coming soon.
The host endpoint is relevant because that is what the controller will
use to look up the associated auth token in the secret. Users will
provide a map of the auth info in the secret data:
Implementation:
:+ port which wouldmake the secret invalid.
In the implementation, we remove the
:portfrom theendpoint. Tostop doing this, we could split the
endpointintoaddressandport, and then gather those together for thefailureDomain.variadic array of opts that we build into a config. This just makes it
nicer to add more options to the client, without having to expand the
signature.
Testing:
can look for, since all the changes are on the client, which we use
fakes for anyway. I will continue to think on it.
Checklist: