-
Notifications
You must be signed in to change notification settings - Fork 930
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
lxc: Prevent accept-certificate flag when using trust token #14149
base: main
Are you sure you want to change the base?
Conversation
e78acd9
to
c611894
Compare
Signed-off-by: Din Music <[email protected]>
If a remote is added, and then removed from the local config (lxc remote delete) and the certificate remains trusted on the remote server, when remote is added again it will fail because it is already trusted. Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
Signed-off-by: Din Music <[email protected]>
c611894
to
639991a
Compare
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.
Please can you add more detail to the commit message explaining what you fixed.
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.
If a remote is added, and then removed from the local config (lxc remote delete)
and the certificate remains trusted on the remote server, when remote is added
again it will fail because it is already trusted.
Is this the current state now and what you've fixed, or what you are changing it to be?
I struggled to understand the change here.
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.
Because:
when remote is added again it will fail because it is already trusted.
Sounds like the wrong behaviour to me, so wanted to understand if this is new or what is being fixed?
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.
This is the current behavior. If remote is removed, and readded, it will fail when trying to add client certificate into remote's trust store, because it is already present there - failing with Client is already trusted
error, and remote not being added.
IMO, we should instead just continue and add the remote.
Example of current behaviour (LXD running in a VM v2
is our remote server):
$ lxc ls
+------+---------+------------------------+-------------------------------------------------+-----------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+---------+------------------------+-------------------------------------------------+-----------------+-----------+
| v2 | RUNNING | 10.70.164.239 (enp5s0) | fd42:2bf4:ef35:8266:216:3eff:fea8:9da4 (enp5s0) | VIRTUAL-MACHINE | 0 |
+------+---------+------------------------+-------------------------------------------------+-----------------+-----------+
# Add the remote (initially).
$ token=$(lxc exec v2 -- lxc config trust add --name test --quiet)
$ lxc remote add test $token
# Remove the remote.
$ lxc remote rm test
# Add the remote (again). The client certificate is already present in remote's trust store.
$ token=$(lxc exec v2 -- lxc config trust add --name test --quiet)
$ lxc remote add test $token
Error: Failed to create certificate: Client is already trusted
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.
Does lxc remote add test
work after doing lxc remote rm test
?
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.
Yes, if target URL is specified:
lxc remote add 10.70.164.239
# or
lxc remote add test 10.70.164.239
When token is used, the address is extracted from the token itself (if specific URL is not provided), so it should work even when token is provided.
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.
Got you. Will the new token still get expired once its used (even though its not really used)?
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.
No, the token is not consumed.
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.
Should it not be? From the user's PoV we've used 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.
Yes, I think that makes sense. Will fix that.
@@ -322,6 +329,11 @@ func (c *cmdRemoteAdd) run(cmd *cobra.Command, args []string) error { | |||
return errors.New(i18n.G("Trust token cannot be used for public remotes")) | |||
} | |||
|
|||
// Certificate cannot be blindly accepted when using a trust 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.
Please can you update the comment to explain the why of this statement.
rawToken, err := shared.CertificateTokenDecode(addr) | ||
if err == nil { | ||
return c.runToken(server, addr, rawToken) | ||
// Certificate cannot be blindly accepted when using a trust token. | ||
if c.flagAcceptCert { |
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.
can we re-structure this commit to avoid needing to check the same logic twice and duplicating the error message?
@@ -2763,7 +2763,7 @@ test_clustering_image_refresh() { | |||
LXD_DIR="${LXD_REMOTE_DIR}" lxc config set core.https_address "10.1.1.104:8443" | |||
|
|||
# Add remotes | |||
lxc remote add public "https://10.1.1.104:8443" --accept-certificate --token foo --public | |||
lxc remote add public "https://10.1.1.104:8443" --accept-certificate --public |
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.
Can we add tests for not being able to use --accept-certificate with tokens please?
Moving to draft until I address all of the above comments. |
This PR prevents
--accept-certificate
to be used with a trust token. Whenever the token is provided, the fingerprint from the token is compared to the remote certificate fingerprint.In addition, validation for mutually exclusive flags is added, more specifically trust token cannot be used with public remotes or when auth-type is OIDC.
Finally, two minor fixes; do not stop interactive mode on wrong input, and do not fail if remote is already trusting us.
Closes #13973
Closes #13891