-
Notifications
You must be signed in to change notification settings - Fork 28
Add option to configure client certificate authentication #40
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
Conversation
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.
🎉 🔒
|
||
| Config (Environment) | Value | | ||
| --- | --- | | ||
| [`http.sslVerify`][sslVerify] (`GIT_SSL_NO_VERIFY`) | `true` for config, `false` for environment var. | |
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.
Ahh consistency 😭
Add a '--tls-version' option, which takes values matching those of the 'http.sslVersion' config in Git, to set the 'tls.Config.MinVersion' setting in the web server. Signed-off-by: Victoria Dye <[email protected]>
|
||
// Sets of flags shared between multiple commands/programs | ||
|
||
type tlsVersionValue uint16 |
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 you want to use tlsVersionValue
in more places (where you currently use uint16
?
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.
The tlsVersionValue
isn't meant to be an externally-facing type, but rather an implementation of flag.Getter
for use with the arg parser. Outside of the initial arg parsing, the value is only used as a uint16
and (because Go doesn't really have enums) it can't provide much in the way of compile-time or runtime checks on the correctness of a TLS version without making usage more cumbersome.
docs/tutorials/mtls.md
Outdated
[Mutual TLS (mTLS)][mtls] is a mechanism for mutual authentication between a server and | ||
client. Configuring mTLS for a bundle server allows a server maintainer to limit | ||
bundle server access to only the users that have been provided with a valid | ||
certificate and establishes confidence that users are interacting with a valid | ||
bundle server. | ||
|
||
[mtls]: https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/ |
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 might be a good time for a warning about how bundle server authentication is completely independent of the origin host authentication.
The biggest differences are:
- You are providing access to all hosted repos to anyone with an appropriate certificate.
- If mirrored repositories have different levels of visibility on the remote host, then you may accidentally provide read access to Git data to someone who does not have access to that repository on the host.
- If the remote host has branch-level security (Gerrit is the only known host to offer this) then the bundles may contain Git objects reachable from restricted branches.
All this is to say, "proceed with caution". Guard these certificates carefully.
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.
I added two sections - one talking about the limitations of mTLS on the bundle server/what to expect, and one urging admins/users to carefully protect their private keys. Let me know if you think anything's missing or needs clarification!
Add a '--client-ca' option to 'git-bundle-web-server' that, when specified, loads a PEM-formatted certificate file and uses the cert(s) within to verify client requests to the bundle web server. If the bundle server has been configured with this option and the client does not send an appropriate certificate, the TLS handshake will fail and the client will be unable to connect. Configuring both server TLS hosting (via the '--cert' and '--key' options) and client cert validation (via '--client-ca') sets up mutual TLS (mTLS) authentication on the bundle web server. Signed-off-by: Victoria Dye <[email protected]>
Add a tutorial detailing how to set up an mTLS-authenticated bundle server. Include a link to the 'docs/tutorials' directory in the repository root 'README.md' to clearly guide users to those resources. Helped-by: Derrick Stolee <[email protected]> Signed-off-by: Victoria Dye <[email protected]>
There are two main changes in this PR:
--tls-version
option togit-bundle-web-server
/git-bundle-server web-server
to set the minimum acceptable TLS version for the web server. Request using a lower version will be rejected; default TLS v1.2.--client-ca
option togit-bundle-web-server
/git-bundle-server web-server
to allow users to specify a certificate authority against which client requests must be validated. Also include a guide on how to set up mTLS using this option & the existing--cert
/--key
when cloning with a bundle URI from Git.