daniel-garcia
commented
4 years ago Our company does have time to implement this feature. If we can get some direction from teleport contributors, we can attempt to implement this feature. Thoughts?
Open daniel-garcia opened 4 years ago
daniel-garcia
commented
4 years ago Our company does have time to implement this feature. If we can get some direction from teleport contributors, we can attempt to implement this feature. Thoughts?
decode13
commented
4 years ago How would Teleport sign the user pubkey without access to CA private key? Build a new tunnel or protocol like SCEP to ask CA to sign the pubkey?
webvictim
commented
4 years ago Services like AWS Cloud HSM do not expose the private key after creation, so this would really be more of a case of Teleport needing to implement a set of operations against an API where it asks an external CA of some kind to perform the signing and trusts its response.
The tricky part here is whether the reference HSMs would support SSH certificate operations as well as x509 operations. SSH certificates don't support intermediate CAs, whereas x509 certificates do. The trust/revocation model is a little clearer for x509.
There is a similar request here: https://github.com/gravitational/teleport/issues/3055
decode13
commented
4 years ago I think is better to first try SoftHSM (https://github.com/opendnssec/SoftHSMv2).
For the SSH certificate, steps are not complicated: 1) HSM/Smartcard needs to have a private key AND an X509 certificate attached to it. Just normal operations of a smartcard 2) Get the SSH key from the HSM into a file: ssh-keygen -D /usr/local/lib/opensc-pkcs11.so This will give you an key like this: ssh-rsa ABCD..... 3) Take the key and put it in a file called: ssh-ca-pub.key 4) Asking to sign with public key will actually instruct HSM which private key to use: ssh-keygen -s ssh-ca-pub.key -D /usr/local/lib/opensc-pkcs11.so -I myuser-idrsa.pub 5) input PIN! (usually smartcards/HSM asks for a PIN to unlock the key. I think OpenHSM has a feature to allow signing without the PIN if the key does not contain one)
For trust, Teleport solved already the problem. For revocation I think is solved: 1) User certs are short lived 2) For CA certs, there is a rotate function in Teleport. Also, if you stop signing with the old key, then you just revoked it. 3) Use already built-in function of OpenSSH:
alwaysastudent
commented
2 years ago Services like AWS Cloud HSM do not expose the private key after creation, so this would really be more of a case of Teleport needing to implement a set of operations against an API where it asks an external CA of some kind to perform the signing and trusts its response.
The tricky part here is whether the reference HSMs would support SSH certificate operations as well as x509 operations. SSH certificates don't support intermediate CAs, whereas x509 certificates do. The trust/revocation model is a little clearer for x509.
There is a similar request here: #3055
Teleport can become an Intermediate CA of an upstream Root CA or in other words, we should be able to supply a CA certificate and private key to Teleport to set up.
nitrocode
commented
2 years ago I worked on this with teleport support.
I modified our Certificate.yaml so it includes the correct issuer* inputs
highAvailability:
certManager:
enabled: true
issuerName: pca-issuer
issuerKind: AWSPCAClusterIssuer
issuerGroup: awspca.cert-manager.ioThe teleport-tls was issued correctly by the AWS PCA Issuer from cert-manager with the aws-pca-issuer addon but the CRT wasn't updated in the chain on the teleport chart.
The fix was to add the following to the teleport chart's deployment.yaml. I'm currently using teleport version 7.3.3.
--- a/chart/teleport-cluster/templates/deployment.yaml
+++ b/chart/teleport-cluster/templates/deployment.yaml
@@ -110,10 +110,15 @@ spec:
env:
{{- toYaml .Values.extraEnv | nindent 8 }}
{{- end }}
+ # This was modified to use PCA which requires copying the ca.crt and updating the ca certs
+ command:
+ - /bin/bash
args:
- - "--diag-addr=0.0.0.0:3000"
+ - "-c"
+ - "cp /etc/teleport-tls/ca.crt /etc/ssl/certs/ && update-ca-certificates && exec teleport start -c /etc/teleport/teleport.yaml --diag-addr=0.0.0.0:3000"
{{- if .Values.insecureSkipProxyTLSVerify }}
- "--insecure"I read this issue as requesting support for keeping CA private key material away from Teleport itself and using it via an abstraction.
Today, Teleport supports:
Coming in Teleport 15, Teleport will also support the use of AWS KMS for storing the private key material. These docs are still a work in progress.
As such, I think this issue can be closed along with the release of Teleport 15.
Feature Request
Teleport uses is own CA certificates. In some infrastructures, private Certificate Authorities are used. This means that applications, like teleport, don't have access to the CA private keys. This feature request is to allow teleport to use a certificate provider and allow it NOT to have access the private CA key.
Motivation
This would provide teleport greater security as the private certificate for the CA is never exposed to teleport.
Who's it for?
I think this is generally applicable to anyone using AWS.