Only return specific identity types from /1.0/certificates #14199
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
markylaing
changed the title
markylaing
changed the title
tomponline
reviewed
Oct 4, 2024
tomponline
reviewed
Oct 4, 2024
tomponline
reviewed
Oct 4, 2024
Probably yes. I'll double check. |
Currently all Certificate methods are getting all identities whose authentication method is "tls". When we add fine-grained TLS identities we don't want to expose these via the certificate API. Rather than filtering these out in the API handlers, this statement can be used to only get the certificates we want from the database. Signed-off-by: Mark Laing <mark.laing@canonical.com>
…dentities. Note that the `GetCertificates` function is never called with a filter. Signed-off-by: Mark Laing <mark.laing@canonical.com>
Signed-off-by: Mark Laing <mark.laing@canonical.com>
Signed-off-by: Mark Laing <mark.laing@canonical.com>
Signed-off-by: Mark Laing <mark.laing@canonical.com>
Signed-off-by: Mark Laing <mark.laing@canonical.com>
Signed-off-by: Mark Laing <mark.laing@canonical.com>
This function is only called in one place with `certificate.TypeServer`. So we don't need to handle the other cases. Signed-off-by: Mark Laing <mark.laing@canonical.com>
This can be replaced with a call to `DeleteIdentitys`. Signed-off-by: Mark Laing <mark.laing@canonical.com>
This function shouldn't be defined on the `*DB` as we're moving as much as possible to just use a `*sql.Tx`. It also isn't making use of the provided `context.Context` argument. Lastly, it is only called in one place so we can just move the transaction to the call site. Signed-off-by: Mark Laing <mark.laing@canonical.com>
Signed-off-by: Mark Laing <mark.laing@canonical.com>
This function is already a helper function and `UpdateCertificate` was only called here. Signed-off-by: Mark Laing <mark.laing@canonical.com>
Signed-off-by: Mark Laing <mark.laing@canonical.com>
markylaing
force-pushed
the
certificate-db-follow-up
branch
from
cfc482e
to
e81185a
Compare
tomponline
approved these changes
Oct 4, 2024
|
Thanks |
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.
In the specification for fine-grained authorization for TLS clients, the
/1.0/certificatesAPI does not return identities of the new type (because they can't be managed via this API).In the PoC PR (#14099) this is done in a bit of a hacky way. They are essentially filtered out because they don't have a matching certificate type.
This PR does this in a more correct way, by ensuring that certificate database queries only return identities of the correct type. I've done some additional clean up as well.