4 ms·

Hi atonse, Russell from Gravitational here. As far as configuring your VPC having the bastion (Proxy) as the only server with a public address is reasonable. O

Hi atonse, Russell from Gravitational here. As far as configuring your VPC having the bastion (Proxy) as the only server with a public address is reasonable. One of the nice things about Teleport is that the Teleport Proxy itself doesn't have access to much, so exposing it to the Internet is fine. The Auth Server is the one that holds sensitive information and we recommend you create a security group for it and only allow it to be accessed from Teleport Proxies or Teleport Nodes. With respect to keys, they are stored and accessed via the Auth Server in Teleport. We recommend you have strong access controls on the Auth Server. If you are using the default backend (BoltDB) or directory based backend that's all you need to do. If you are using etcd we recommend you have strong access controls on the server that runs etcd as well as etcd itself, we have an example in our Teleport repo for etcd configuration if you're interested[1]. If you are using DynamoDB, we recommend having a strong IAM policy. We are not using Vault at the moment. [1] https://github.com/gravitational/teleport/tree/master/examples/etcd https://github.com/gravitational/teleport/tree/master/exampl...

old-gregg 9y ago
Speaking of Vault, AFAIK the community expressed a lot of interest in providing custom secret storage plugins, so the latest releases have had a much simpler storage interface to implement, which is how DynamoDB was added, someone just sent a PR: https://github.com/gravitational/teleport/tree/master/lib/backend/dynamo https://github.com/gravitational/teleport/tree/master/lib/ba...
atonse 9y ago
Great, thanks for the info!
walrus01 9y ago
> Teleport Proxy itself doesn't have access to much, so exposing it to the Internet is fine. yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway (or IPSEC VPN) with a public interface, and a private interface facing inwards towards the hosts. you should not even be able to route to the IP of the thing you want to SSH to unless you've authenticated to the VPN and your client device has been handed out an IP in your RFC1918 IP space. a machine like an openvpn gateway can also serve the purpose of getting you access into an OOB network (example: a public facing IP on a 100Mbps DIA circuit you've bought from a totally diverse ISP in the same colo, with a static /30), which has access into internal IP space devices such as serial console servers and ssh bastion hosts. authenticate the clients by a unique public/private key pair per client device. Easy to revoke a specific device's key from the server side if needed.
- alexk 9y ago
  > yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway This is not a bad idea in general. In fact, teleport proxy implements this exact model you have just described, where only proxy is available and acts as a jump host to the set of machines available only on the private net. The only difference is that instead of open VPN gateway it uses SSH jumphost model. Teleport proxy uses OpenSSH cert auth, in addition to that teleport node also does cert auth. Not everyone needs to always set up VPN, sometimes jumphosts + cert auth are perfectly fine.
  - walrus01 9y ago
    I encourage all of my competition to allow access to relay to critical internal things with only SSH based authentication on a bastion/proxy, and nothing else.
    - alexk 9y ago
      This is not how SSH jumphosts and Teleport Proxy work. With jumphost ssh client goes through the authentication and authorization twice: * first when connecting to the jumphost public ip and requesting to execute a subsystem to allow proxying to some internal IP/host Jumphost does not terminate the SSH and in fact it is MITM capabilities are very limited. * Second time authentication and authorization happens when ssh client connects to the target SSH node. This pattern is in fact quite modern and is being expanded in the beyond corp architecture. https://research.google.com/pubs/pub43231.html https://research.google.com/pubs/pub43231.html It deprecates perimeter security model that you mention via VPN gateways and replaces it with on-demand end to end access via controlling gateway.
      - throw049483498 9y ago
        Yeah but the security model it implements is vulnerable to any new remote code execution that pops up for OpenSSH. With the VPN as your boundary, you can configure it so the VPN doesn't even respond to packets unless they are TLS authenticated. A huge security win, you're not exposed to random attempts to do remote code execution against your open sockets!

old-gregg 9y ago

Speaking of Vault, AFAIK the community expressed a lot of interest in providing custom secret storage plugins, so the latest releases have had a much simpler storage interface to implement, which is how DynamoDB was added, someone just sent a PR: https://github.com/gravitational/teleport/tree/master/lib/backend/dynamo https://github.com/gravitational/teleport/tree/master/lib/ba...

atonse 9y ago

Great, thanks for the info!

walrus01 9y ago

> Teleport Proxy itself doesn't have access to much, so exposing it to the Internet is fine. yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway (or IPSEC VPN) with a public interface, and a private interface facing inwards towards the hosts. you should not even be able to route to the IP of the thing you want to SSH to unless you've authenticated to the VPN and your client device has been handed out an IP in your RFC1918 IP space. a machine like an openvpn gateway can also serve the purpose of getting you access into an OOB network (example: a public facing IP on a 100Mbps DIA circuit you've bought from a totally diverse ISP in the same colo, with a static /30), which has access into internal IP space devices such as serial console servers and ssh bastion hosts. authenticate the clients by a unique public/private key pair per client device. Easy to revoke a specific device's key from the server side if needed.

alexk 9y ago
> yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway This is not a bad idea in general. In fact, teleport proxy implements this exact model you have just described, where only proxy is available and acts as a jump host to the set of machines available only on the private net. The only difference is that instead of open VPN gateway it uses SSH jumphost model. Teleport proxy uses OpenSSH cert auth, in addition to that teleport node also does cert auth. Not everyone needs to always set up VPN, sometimes jumphosts + cert auth are perfectly fine.
- walrus01 9y ago
  I encourage all of my competition to allow access to relay to critical internal things with only SSH based authentication on a bastion/proxy, and nothing else.
  - alexk 9y ago
    This is not how SSH jumphosts and Teleport Proxy work. With jumphost ssh client goes through the authentication and authorization twice: * first when connecting to the jumphost public ip and requesting to execute a subsystem to allow proxying to some internal IP/host Jumphost does not terminate the SSH and in fact it is MITM capabilities are very limited. * Second time authentication and authorization happens when ssh client connects to the target SSH node. This pattern is in fact quite modern and is being expanded in the beyond corp architecture. https://research.google.com/pubs/pub43231.html https://research.google.com/pubs/pub43231.html It deprecates perimeter security model that you mention via VPN gateways and replaces it with on-demand end to end access via controlling gateway.
    - throw049483498 9y ago
      Yeah but the security model it implements is vulnerable to any new remote code execution that pops up for OpenSSH. With the VPN as your boundary, you can configure it so the VPN doesn't even respond to packets unless they are TLS authenticated. A huge security win, you're not exposed to random attempts to do remote code execution against your open sockets!