-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
validate capi-auth-token on dqlite/remove #56
validate capi-auth-token on dqlite/remove #56
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, did a first pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, some first comments.
} | ||
|
||
// RemoveFromDqlite implements the "POST /v2/dqlite/remove" endpoint and removes a node from the dqlite cluster. | ||
func (a *API) RemoveFromDqlite(ctx context.Context, req RemoveFromDqliteRequest) (int, error) { | ||
func (a *API) RemoveFromDqlite(ctx context.Context, req RemoveFromDqliteRequest, token string) (int, error) { | ||
isValid, err := a.Snap.IsCAPIAuthTokenValid(token) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me, the validation of the token is a separate middleware/access handler that could potential be reused for other endpoints (similar to what we do in k8s-snap)
Disclaimer: I don't know much about the microk8s cluster agent. If this matches the other code structure I'm fine with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like what you're saying, but IIUC the middlewares are not configurable per endpoint in cluster-agent: https://github.com/canonical/microk8s-cluster-agent/blob/main/pkg/server/server.go#L45-L46
All the v1 or v2 endpoints get registered with the same middleware.
We technically can have this capi-auth-token
header check as a middleware, but since it's going to get applied for the other v2 endpoints as well (/image/import
and /join
) we need to make it optional, which is counter intuitive. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can simply set a new middleware on a per route basis:
https://github.com/canonical/microk8s-cluster-agent/blob/main/pkg/server/server.go#L19-L27
For this route you would add it here:
https://github.com/canonical/microk8s-cluster-agent/pull/56/files#diff-6ecd338993def4d5349db1e632bfa290c6aa5d6a7e04e6413f0f27e8983161f3R58
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, thanks for pointing this out. Will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bschimke95 This is the best that I could come up with. TBH I feel like the previous implementation was more readable and understandable. Maybe I'm doing something wrong. WDYT?
2bcaeca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reverting this. Not really happy with the result...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, up to you. This was only a suggestion. If you think the current implementation is more straight-forward - go for it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
} | ||
|
||
// RemoveFromDqlite implements the "POST /v2/dqlite/remove" endpoint and removes a node from the dqlite cluster. | ||
func (a *API) RemoveFromDqlite(ctx context.Context, req RemoveFromDqliteRequest) (int, error) { | ||
func (a *API) RemoveFromDqlite(ctx context.Context, req RemoveFromDqliteRequest, token string) (int, error) { | ||
isValid, err := a.Snap.IsCAPIAuthTokenValid(token) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, up to you. This was only a suggestion. If you think the current implementation is more straight-forward - go for it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Although initially we had the os.GETENV("CAPI_PATH")
that could override the default path. Did we forget to change the cluster agent command to use the WithCAPIPath
option?
@berkayoz I think the
Did I understand your point correctly? |
According to a conversation with @berkayoz, we decided to go with hard-coding that path for now and see if we need to make that configurable later on. Note for future travelersThe path defined here should match the one in the "Microk8s CAPI bootstrap provider". That provider is responsible for populating this path with needed files and info (e.g. CAPI auth token). |
Summary
This PR adds the
capi-auth-token
header validation for thedqlite/remove
endpoint.The
/capi/etc/token
file is supposed to get created by the Microk8s bootstrap provider (in the cloud-init) and will get populated with a token string which is used to authenticate the CAPI calls (thedqlite/remove
call specifically) to the cluster-agent.Also the
removeEndpoint
request field is changed toremove_endpoint
to comply with the recent MAAS API guidelines.Alternative solution
We could have a "create capi token" endpoint that creates the token file and returns the /path/to/token as well as the token itself. Right now we introduced some coupling between Microk8s CAPI and cluster-agent since they both should be aware that the token path is
/capi/etc/token
. Implementing this solution and improving on the current implementation might be considered later.PR series