Remoteler issues short-lived X.509 certs and updates Kubernetes clients to talk to Remoteler Proxy Service using mutual TLS. It then intercepts every request and adds impersonation headers to map users to Kubernetes users and groups.

Let’s consider a simple environment on a private network with a single Kubernetes cluster. To enable access to this cluster from a public network via Remoteler:

• The Kubernetes integration must be enabled in the Remoteler Proxy Service configuration file.
• The Remoteler Proxy Service should be given Kubernetes API access with permissions to use the user impersonation. The easiest way to do this is to deploy the Remoteler Proxy Service into a Kubernetes cluster and give its service account the right permissions.

The location of the Remoteler Auth Service does not matter as long as the Remoteler Proxy Service can connect to it. If SSH connectivity is required, any SSH node can be accessed via Remoteler regardless of whether it is a part of Kubernetes or not, as long as:

• The Remoteler Proxy Service can connect to a node.
• A node can connect to the Remoteler Auth Service.

The diagram below illustrates the typical Remoteler deployment into a Kubernetes cluster.

In the example above:

1. Remoteler Proxy and Remoteler Auth services are both deployed into the Kubernetes cluster as pods.
2. Connections over the internal Kubernetes cluster network are marked as “A” and connections from outside the Kubernetes network are marked as “B”.
3. Remoteler Proxy Service is exposed to the outside world via a Kubernetes service of the Load Balancer type. It has a fully qualified domain name with proper HTTP/TLS encryption, in this example it is https://proxy.example.com
4. Remoteler Auth Service is exposed to the internal network (but external to Kubernetes), i.e. a VPC on AWS or VLAN in a traditional data center, the same network on which non-Kubernetes SSH nodes are running.

The Remoteler Auth Service maintains a list of Remoteler roles. Each Remoteler role is mapped to a set of Kubernetes groups and they, in turn, are mapped to an identity provider such as Okta or Active Directory. This is how synchronization of permissions works across SSH and Kubernetes.

On the client, users must authenticate using the tsh command-line utility, which opens the web browser if SSO authentication is configured. Upon successful authentication, tshautomatically updates ~/.kube/config file for all Kubernetes tools:

The access will be automatically revoked when the Teleport-issued certificate’s time to live (TTL) expires. Users may also explicitly log out if using someone else’s untrusted computer:

$ tsh logout

If Remoteler is configured with multiple Kubernetes clusters, users may choose which one to connect to by executing tsh login <cluster-name>. If a user already has a valid certificate, this command does not trigger the SSO login prompt. It only updates ~/.kube/config with the selected cluster.

As you can see, each Kubernetes cluster becomes a Remoteler cluster if Remoteler is deployed inside of one. Remoteler has the ability to connect multiple clusters together. For example, you have multiple Kubernetes clusters set up similarly to the diagram above, you can configure Remoteler to proxy users between multiple clusters.

This capability is called “Trusted Clusters” or “Remote Clusters” and you can read more about it in the SSH and Kubernetes on the Edge page.