RFD 0178: GitHub proxy

[greedy52]

rendered: https://github.com/gravitational/teleport/blob/rfd/0178-github-proxy/rfd/0178-github-proxy.md

poc branch https://github.com/gravitational/teleport/tree/STeve/proxy_github_v5

[smallinsky]

First quick pass.

[smallinsky]

Just a thought:

The GitHub organization node allows access to repositories with built-in permissions.

I wonder if there is a way to delegate permission management for GitHub via Teleport's RBAC model and enforce RBAC checks at the protocol level.

For instance, using an RBAC role to define the repositories and operations a user is allowed to perform, and enforcing this at the GitHub protocol level so if we can audit GH action we can model the GH RBAC in teleport.

[greedy52]

For instance, using an RBAC role to define the repositories and operations a user is allowed to perform, and enforcing this at the GitHub protocol level so if we can audit GH action we can model the GH RBAC in teleport.

I think the repo and action (fetch vs push) are the only ones we can control.

Like you said in other comments, today we are relying on the Organization that has existing GitHub users. Users can still perform actions through Web UI.

[smallinsky]

Right now, the GitHub Proxy seems to be a good fit for automation flows like CI, but missing support for GitHub web UI access will be a blocker for day-to-day user workflows. Alternatively, we could rely on two access models, such as GitHub SSO and Teleport GitHub Proxy, but this raises the question: why use the GitHub Proxy when a user already has access to GitHub via SSO?

[greedy52]

RBAC should be controlled with GitHub IAM integrartion. The proxy is more like an addon to it. As mentioned in the stories, the benefit using the GitHub Proxy include per-session MFA, audit log (e.g. generating reporting using Access Monitoring). I can certainly add specific stories for those like I want to generate an audit report that xxx

[r0mant]

I think that role spec and internal representation of Github's "server" need a bit more work. Reusing part of SSH implementation since git is essentially SSH protocol is one thing but from the UX and configuration perspective it is very confusing that it relies on access controls designed for SSH nodes, feels like leaking implementation details.

It would also be helpful to see an end-to-end MVP in action that showcases your user scenarios e.g. a demo where:

• An admin goes to Integrations tab and sets up Github integration.
• A user logs into Teleport and uses git to interact with the repository.

[r0mant]

Do we need this both in the labels and in the spec?

[greedy52]

this is for RBAC. it will be a lot better to switch to repo-specific RBAC! will update!

[r0mant]

It is fairly confusing to use node_labels and logins for Github access. I understand we're relying on a lot of SSH implementation under the hood but from user's perspective this is very confusing.

First of all - why do we need "logins"? There will never be a list here as each user will have a single Github username in 99% of cases, can we just take it directly from the user's traits?

For the labels - instead of using node labels can we piggy-back on the role spec proposed in Github IAM RFD and extend the repo_permissions section with something like this:

spec:
  allow:
    repo_permissions:
    - orgs:
      - goteleport

[greedy52]

Maybe I am overthinking this. How do we plan to differentiate between different types of Git hostings? For example, both GitHub and GitLab can have organizations.

For the proxying purpose, what do you think something like this?

spec:
  allow:
    github_organizations:
    - my-org

[r0mant]

We can just call it github_permissions rather than generic repo_permissions I think. So:

  allow:
    github_permissions:
      orgs:
      - gravitational
      repos:
      - teleport
      - teleport.e
      roles:
      - push

[r0mant]

I think this will increase the amount of work we need to do to treat these node resources specially. If we use node resource, we'll probably have to take a special care then to filter it out from things like "tsh ls" and web UI listing of nodes, etc. Can we use a different resource type instead? cc @rosstimothy @espadolini

[greedy52]

I think it will be more work to make existing transport take another resource kind (but still types.Server) but i agree it's cleaner that way. Let me look into that.

[r0mant]

Suggested change

	Command" events will replace the "Command Executation" events:
	Command" events will replace the "Command Execution" events:

[viktor-doyensec-teleport]

Hi team!

I completed the review of the RDF. The concerns outlined in the "Security" section are valid. Both suggested alternatives would help prevent potential account impersonation, and the listed trade-offs are accurate.

I have, however, a questions regarding the "Alternative 2" proposal. Have you looked into the extension:id@github.com extension when signing user certificates? It seems to be a more stable/immutable way of identifying GitHub users.

From my limited testing, changing an account's username does not have impact its ID.

Given that, a variant of the "Alternative 2" flow might be:

1. Require the user to go through the GitHub OAuth flow
2. Store the user's GitHub account ID in an account trait
3. Use the GitHub account ID to sign a user certificate

Once the GitHub account ID is stored, the OAuth flow should no longer be required. This should help smooth out the UX and reduce the number of times the user needs to perform the OAuth flow. If the user wishes to use another GitHub account later on, the ID can be overwritten by requiring the user to go through the above flow once more.

Let me know what are your thoughts on this.

[r0mant]

This is too low-level for the enrollment flow, we should just create this server resource internally automatically.

[r0mant]

What would the flow be in a non-interactive/headless scenario? I.e. if you want to do this from a development box where there is no browser.

[r0mant]

To follow up on my question above, sounds like this should work for scenarios where you do tsh login from a development box and not your laptop as well, correct? Have you tested this scenario? Can we give them a link to click instead of opening the browser?

[greedy52]

As discussed in person, one mitigation we decided to do is to preserve github identity info so user only needs to do OAuth flow once on their laptop.

I found today user login state is refreshed upon new user login. I have updated the refresh logic to preserve the github identity info during refresh so that another login wouldn't void the GitHub OAuth flow. We might need a way to properly void the GitHub identity saved though. I might add a tctl call later or adjust tsh git login.

The other alternative is port-forwarding. For example, from user's laptop:

(local)$ tsh ssh -L 8080:localhost:8080 bob@remote-box
(remote)$ tsh login xxxx
(remote)$ tsh git login --github-org my-org --callback-addr localhost:8080

Then bob can open the URL on his laptop's browser to finish the flow.

I will update the RFD to reflect this.

[r0mant]

This is no longer true so probably should be removed or marked as discarded design.

[r0mant]

lgtm once you've made the changes we discussed in the latest feedback round