programmerq
commented
1 year ago https://github.com/gravitational/teleport/issues/21238 seems related
Open programmerq opened 2 years ago
programmerq
commented
1 year ago https://github.com/gravitational/teleport/issues/21238 seems related
TeleLos
commented
1 year ago I see same behavior when the application is installed using teleport-kube-service. Root Cluster: 12.3.1 (telepor.sh), Grafana app named grafana connected using teleport-kube-agent v12.2.4 Leaf Cluser: 11.3.9 (cloud.gravitational.io) , Grafana app named grafana connected using teleport-kube-agent v11.3.5
Connect to root cluster UI. Select the leaf cluster in the drop down menu Select Applications in the Resources menu Launch the grafana application
You will be directed to the grafana app of the root server instead of the leaf.
Tener
commented
1 year ago The URL for different apps on different leaf clusters with the same name is, unfortunately, shared. This means the user can only be logged in to one of those simultaneously within the same browser session. Using multiple separate browser profiles works but is unwieldy.
The good news is that the login link is stable and can be bookmarked. This is the URL behind "Launch" button. You can copy the link it leads to without hassle. For example, app "dumper" on leaf cluster accessed via root cluster:
https://root.teleport.example.com:3080/web/launch/dumper.root.teleport.example.com/leaf.teleport.example.com/dumper.leaf.teleport.example.comNow, I can imagine extending the current routing scheme to distinguish apps between leaf clusters. For example, given leaf cluster:
> tctl get remote_cluster
kind: remote_cluster
metadata:
id: 1684509092991901000
name: leaf.teleport.example.com
status:
connection: online
last_heartbeat: "2023-05-19T15:11:22.939414Z"
version: v3We could use cluster name or cluster id (potentially encoded), to create scoped URL. Some ideas:
1684509092991901000-jenkins.root.teleport.examplecsqcmy5rgkzs-jenkins.root.teleport.example
Description
What happened:
Given a root cluster that has two leaf clusters that happen to have application access instances with the same name, there is no way to differentiate which leaf cluster needs to be used when accessing the application by URL.
Say I have multiple leaf clusters that all have a 'jenkins' application, and my root cluster is teleport.example.com.
If I navigate to jenkins.teleport.example.com, I will be prompted to authenticate to the root cluster, and then I will be redirected to one of the leaf cluster applications that has the name "jenkins". I don't know which leaf cluster's jenkins instance I will end up on, and there's no obvious way to force it to switch once logged in.
What you expected to happen:
Users should be able to share permalinks to leaf clusters accessed through a root cluster without asking the user to remember to first navigate to the root cluster application pane and manually select the application to launch.
Reproduction Steps
As minimally and precisely as possible, describe step-by-step how to reproduce the problem.
<appname>.<rootcluster>and observe that you are prompted to log in and then get dropped on a seemingly arbitrary instance.Server Details
teleport version): 8.3.2/etc/os-release): n/aClient Details
tsh version): n/aDebug Logs
Please include or attach debug logs, when appropriate. Obfuscate sensitive information!
teleport --debug)tsh --debug)Here's the logs from the root cluster authproxy node logs at the time that the user logs in when navigating to the appname on the root cluster. It seems to just pick a leaf cluster and go with it even though there are multiple applications with that name.
Additionally, if a user tries to access an application on one leaf cluster using the teleport gui "launch" selector, it'll silently log them out of the other one since they will all be accessed over the same exact DNS name. The session seems to get updated to point to only one cluster at a time.
gz#4221