Trusted clusters in OSS version of Teleport cannot be set up

[kontsevoy]

The notion of "Role" is absent in the OSS Teleport. Therefore I have the following definition of a trusted cluster:

kind: trusted_cluster
version: v2
metadata:
  name: east
spec:
  enabled: true
  token: dogs-are-great
  tunnel_addr: ev-t1-master:3024
  web_proxy_addr: ev-t1-master:3080

I successfully create it, because I have added the following snipped to CheckAndSetDefaults():

if !lib.IsEnterprise(){
    // OSS teleport uses 'admin' by default:
    c.Spec.Roles = []string{teleport.AdminRoleName}
}

... basically added 'admin' role to the trusted cluster spec.

The trusted cluster is established and I can see it via tsh clusters. But when I try to connect, I get "access denied" and here's what I see in the logs:

(with nicer formatting)

ERRO Permission denied: user ekontsevoy@ev-t1-master is not authorized to login as ekontsevoy@ev-t2-master: 
access to node ev-t2-master is denied to role(s): 

[
  role admin denied access: allow rules did not match; match(namespace=true, label=true, login=false) 
  role default-implicit-role denied access: allow rules did not match; match(namespace=true, label=false, login=false)
]  

file="srv/sshserver.go:699" fingerprint="ssh-rsa-cert-v01@openssh.com SHA256:VcyzfFxlQLkcTYCcjachaiTOTxOWa0lA/Das6fpKOWM" func="srv.(*Server).keyAuth" local="127.0.0.1:3022" remote="192.168.1.16:34088" user=ekontsevoy

Dump of the trusted cluster:

$ tctl get cluster/oss

kind: trusted_cluster
version: v2
metadata:
  name: oss
spec:
  enabled: true
  role_map:
  - local:
    - admin
    remote: admin
  token: dogs-are-great
  tunnel_addr: ev-t1-master:3024
  web_proxy_addr: ev-t1-master:3080

So the role mapping appears to be set. Yet it still won't let me in even though I'm an admin.

Here's my "admin" role on the cluster that's denying me access:

ev-t2-master ~: tctl get role/admin

kind: role
version: v3
metadata:
  name: admin
spec:
  allow:
    logins:
    - '{{internal.logins}}'
    node_labels:
      '*': '*'
    rules:
    - resources:
      - role
      verbs:
      - connect
      - list
      - create
      - read
      - update
      - delete
    - resources:
      - auth_connector
      verbs:
      - connect
      - list
      - create
      - read
      - update
      - delete
    - resources:
      - session
      verbs:
      - list
      - read
    - resources:
      - trusted_cluster
      verbs:
      - connect
      - list
      - create
      - read
      - update
      - delete
  deny: {}
  options:
    max_session_ttl: 30h0m0s

[kontsevoy]

Update

I looked at the code. The remote users (i.e. users coming from remote clusters) do not have their "traits" available for evaluation against {{internal.logins}}. I looked into ApplyTraits() function and it always gets nil for its second parameter.

By the way, here's my certificate, issued by the master cluster: (i.e. the cert I can't use to login):

ekontsevoy-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT SHA256:vd9Rozqeun4AfcAizjnLWWNhLN2cG7/5RXf4huK6/Q8
        Signing CA: RSA SHA256:SP/h9VeDELHurs5lKSFhdqbDqNqxdPoGdN7G6hw3HqE
        Key ID: "ekontsevoy"
        Serial: 0
        Valid: before 2017-09-11T04:08:37
        Principals: 
                ekontsevoy
                root
        Critical Options: (none)
        Extensions: 
                permit-port-forwarding
                permit-pty
                teleport-roles UNKNOWN OPTION (len 38)

[klizhentas]

In both OSS and Enterprise mode we should evaluate SSH cert principals for internal.logins and covert them to traits for remote trusted clusters. @russjones talk to me before doing this ticket.

[klizhentas]

Here when fetching roles, for remote users, we should call ApplyTraits:

https://github.com/gravitational/teleport/blob/master/lib/srv/sshserver.go#L526

to allow roles to process internal.logins