You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been thinking about we would add TLS and encryption in every layer. Currently, there are two kinds of services: internal services, consumed by tsuru components, and external services, consumed by external clients (tsuru API and the router).
External services require a valid certificate, issued by a CA of trust to all external clients. Internal services could use a CA trusted only by tsuru components.
tsuru API already supports TLS. #1206 is open to address TLS in the router (if the router supports SNI, or something like that). I'd like to propose extending TLS support to other components.
Gandalf does not support TLS yet (see tsuru/gandalf#192). The information that flows through Gandalf is not very sensitive (public SSH keys, user emails and repository names), but it would be nice to have
Application containers can terminate TLS today, as long as they provide their own certificate and private key, which isn't nice (imagine an open source application that is also deployed on tsuru).
Docker and Docker Registry also support TLS, but we don't use it today. #1223 should address some kind of certificate management in tsuru, because Docker Machine will spawn TLS-enabled Docker hosts. Docker and Docker Registry are both internal services, consumed only by tsuru components.
What I propose here, for internal services, is:
create a CA for tsuru, and ensure that all components trust this authority
automatically generate private keys and certificates for application (i.e. each application will have a private key and a certificate stored inside the containers, so application could terminate TLS without having to )
automatically generate private keys and certificates for Docker nodes created via the IaaS interface (including Docker Machine)
use a certificate generated by tsuru CA for Docker Registry, Gandalf and other TLS-capable internal services (e.g.: vulcand admin API)
Any thoughts on this?
The text was updated successfully, but these errors were encountered:
https://github.com/tsuru/dockerized-setup uses docker-machine to create the tsuru admin docker node.
Then we should be able to add new docker nodes via docker-machine.
But it doesn't work because the nodes are created with TLS verification and tsuru doesn't support it.
I've been thinking about we would add TLS and encryption in every layer. Currently, there are two kinds of services: internal services, consumed by tsuru components, and external services, consumed by external clients (tsuru API and the router).
External services require a valid certificate, issued by a CA of trust to all external clients. Internal services could use a CA trusted only by tsuru components.
tsuru API already supports TLS. #1206 is open to address TLS in the router (if the router supports SNI, or something like that). I'd like to propose extending TLS support to other components.
Gandalf does not support TLS yet (see tsuru/gandalf#192). The information that flows through Gandalf is not very sensitive (public SSH keys, user emails and repository names), but it would be nice to have
Application containers can terminate TLS today, as long as they provide their own certificate and private key, which isn't nice (imagine an open source application that is also deployed on tsuru).
Docker and Docker Registry also support TLS, but we don't use it today.
#1223 should address some kind of certificate management in tsuru, because Docker Machine will spawn TLS-enabled Docker hosts. Docker and Docker Registry are both internal services, consumed only by tsuru components.
What I propose here, for internal services, is:
Any thoughts on this?
The text was updated successfully, but these errors were encountered: