-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitHub proxy part 6: proxing Git using SSH transport #49980
base: master
Are you sure you want to change the base?
Conversation
73db1b8
to
1cd0ec1
Compare
a5cb9a6
to
97bbddf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure that hooking into lib/srv/forward.Server
to essentially add a completely separate mode gated by a flag (or like three different and potentially conflicting flags) is easier than writing something new that's going to be structurally guaranteed to work as intended just for the purpose of forwarding the ssh git protocol?
// GitServerGetter defines a service to get Git servers. | ||
services.GitServerGetter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If ClientI
already has a way to get a gitserver.Client
which has GetGitServer
and ListGitServers
, why do we need to extend ClientI with methods at the top level?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are casting ClientI
to ProxyAccessPoint
in a few places, which forces authclient to have same interface as Cache. Also gitserver.Client
is not suitable for "AccessPoint".
one other option is to have a gitserver.ReadOnlyClient
or decouple ClientI
from ProxyAccessPoint
somehow. any recommendation is welcome.
will do 👍 |
i am splitting out some parts of this PR to separate ones like |
97bbddf
to
2345ca3
Compare
@greedy52 - this PR will require admin approval to merge due to its size. Consider breaking it up into a series smaller changes. |
@espadolini PTAL |
} | ||
|
||
// Use auth.UserKeyAuth to verify user cert is signed by UserCA. | ||
permissions, err := s.auth.UserKeyAuth(conn, key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will also do regular RBAC on the TargetServer
unless you also change the check for h.c.Component == teleport.ComponentForwardingNode
in authhandlers.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a check to avoid that:
teleport/lib/srv/authhandlers.go
Lines 471 to 473 in 67c298b
if h.isProxy() || h.c.Component == teleport.ComponentForwardingGit { | |
return permissions, nil | |
} |
but in the long run, we should do some refactoring to have dedicated auth handler for each type.
return true, nil | ||
case sshutils.ExecRequest: | ||
return true, trace.Wrap(s.handleExec(ctx, ch, req, remoteSession)) | ||
case sshutils.EnvRequest: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we ever want and/or need envvars in the ssh git protocol?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
openssh sends LANG
and GIT_PROTOCOL
(when using v2 protocol). they are optional but it would be nice to forward them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments.
In general, I wonder about the decision to reuse ssh connection functionality for this. If we ever want to support other protocols then suddenly we need to reinvent a lot of things. The implementation ends up rather intrusive as we need to hijack a number of bits, e.g. the routing to nodes.
I assume this point was discussed before, so I'm keen to learn the rationale behind this vs e.g. reusing the infrastructure for TCP apps.
I can't speak for the decision to use the git ssh protocol vs the git http protocol, but if we're going to use the git ssh protocol, reusing our existing SSH transport makes sense IMO. My initial recommendation was to actually make the configuration bits real static nodes in a similar fashion to the openssh ones, but we've decided to use a dedicated configuration type for git servers. |
The very first git proxy poc is actually http-based for AWS CodeCommit using AWS app access. But AWS CodeCommit is dead now. Like Edoardo said, this is what we end up with after a few iterations of poc and RFD discussions. GitLab supports SSH CA as well. Even if we have to do HTTP later, I don't think it's that difficult. |
b05b384
to
58ca650
Compare
@espadolini @Tener could you take another look? thanks! |
Related:
will stack another PR for
tsh git ssh/config/clone
commands on top of this