client: set TLS certificate usage for k8s/app/db certs #6824
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
Joerger
approved these changes
May 12, 2021
andrejtokarcik
approved these changes
May 12, 2021
|
FWIW,
is not entirely correct. The file still gets overwritten, just with the old already-stored cert.
Has this ever been the case? |
added 2 commits
May 13, 2021 09:52
--- TLS usage field The certificate usage field prevents a certificate from being used for other purposes. For example, a k8s-specific certificate will not be accepted by a database service endpoint. Server-side enforcement logic was already in place for a long time, but we stopped setting the correct Usage in UserCertRequest during keystore refactoring in 5.0 (with introduction of k8s certs). --- TLS certificate overwrite As part of this, client.ReissueUserCerts will no longer write usage-restricted certificates into the top-level TLS certificate used for Teleport API authentication. For example, when generating a k8s-specific certificate, we used to overwrite both: - `~/.tsh/keys/$proxy/$user-x509.pem` - `~/.tsh/keys/$proxy/$user-kube/$cluster/$kubeCluster-x509.pem` This PR stops overwriting `~/.tsh/keys/$proxy/$user-x509.pem`. This is not a breaking change. --- Selected k8s cluster Prior to this PR, `tsh status` printed the selected k8s cluster based on the top-level TLS certificate. Since we no longer overwrite that certificate, it will not contain a k8s cluster name. Instead, we extract it from the kubeconfig, which is actually more accurate since a user could switch to a different context out-of-band.
awly
force-pushed
the
andrew/tls-cert-usage
branch
from
2796fe2 to
4e29eb9
Compare
That's correct. It's overwritten but not changed.
I think so. Before 5.0, we only ever had 1 SSH and 1 TLS cert in the profile directory (per cluster). |
awly
pushed a commit
that referenced
this pull request
May 13, 2021
* client: set TLS certificate usage for k8s/app/db certs --- TLS usage field The certificate usage field prevents a certificate from being used for other purposes. For example, a k8s-specific certificate will not be accepted by a database service endpoint. Server-side enforcement logic was already in place for a long time, but we stopped setting the correct Usage in UserCertRequest during keystore refactoring in 5.0 (with introduction of k8s certs). --- TLS certificate overwrite As part of this, client.ReissueUserCerts will no longer write usage-restricted certificates into the top-level TLS certificate used for Teleport API authentication. For example, when generating a k8s-specific certificate, we used to overwrite both: - `~/.tsh/keys/$proxy/$user-x509.pem` - `~/.tsh/keys/$proxy/$user-kube/$cluster/$kubeCluster-x509.pem` This PR stops overwriting `~/.tsh/keys/$proxy/$user-x509.pem`. This is not a breaking change. --- Selected k8s cluster Prior to this PR, `tsh status` printed the selected k8s cluster based on the top-level TLS certificate. Since we no longer overwrite that certificate, it will not contain a k8s cluster name. Instead, we extract it from the kubeconfig, which is actually more accurate since a user could switch to a different context out-of-band. * Document UserCertRequest CertUsage enum values
awly
pushed a commit
that referenced
this pull request
May 13, 2021
* client: set TLS certificate usage for k8s/app/db certs --- TLS usage field The certificate usage field prevents a certificate from being used for other purposes. For example, a k8s-specific certificate will not be accepted by a database service endpoint. Server-side enforcement logic was already in place for a long time, but we stopped setting the correct Usage in UserCertRequest during keystore refactoring in 5.0 (with introduction of k8s certs). --- TLS certificate overwrite As part of this, client.ReissueUserCerts will no longer write usage-restricted certificates into the top-level TLS certificate used for Teleport API authentication. For example, when generating a k8s-specific certificate, we used to overwrite both: - `~/.tsh/keys/$proxy/$user-x509.pem` - `~/.tsh/keys/$proxy/$user-kube/$cluster/$kubeCluster-x509.pem` This PR stops overwriting `~/.tsh/keys/$proxy/$user-x509.pem`. This is not a breaking change. --- Selected k8s cluster Prior to this PR, `tsh status` printed the selected k8s cluster based on the top-level TLS certificate. Since we no longer overwrite that certificate, it will not contain a k8s cluster name. Instead, we extract it from the kubeconfig, which is actually more accurate since a user could switch to a different context out-of-band. * Document UserCertRequest CertUsage enum values
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.
TLS usage field
The certificate usage field prevents a certificate from being used for
other purposes. For example, a k8s-specific certificate will not be
accepted by a database service endpoint.
Server-side enforcement logic was already in place for a long time, but
we stopped setting the correct Usage in UserCertRequest during keystore
refactoring in 5.0 (with introduction of k8s certs).
TLS certificate overwrite
As part of this, client.ReissueUserCerts will no longer write
usage-restricted certificates into the top-level TLS certificate used
for Teleport API authentication.
For example, when generating a k8s-specific certificate, we used to
overwrite both:
~/.tsh/keys/$proxy/$user-x509.pem~/.tsh/keys/$proxy/$user-kube/$cluster/$kubeCluster-x509.pemThis PR stops overwriting
~/.tsh/keys/$proxy/$user-x509.pem.This is not a breaking change.
Selected k8s cluster
Prior to this PR,
tsh statusprinted the selected k8s cluster based onthe top-level TLS certificate. Since we no longer overwrite that
certificate, it will not contain a k8s cluster name.
Instead, we extract it from the kubeconfig, which is actually more
accurate since a user could switch to a different context out-of-band.
Updates #6161
Updates #5815