Skip to content

Enabling mTLS between kraken services #390

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

Closed
wants to merge 18 commits into from
Closed

Enabling mTLS between kraken services #390

wants to merge 18 commits into from

Conversation

hweawer
Copy link
Collaborator

@hweawer hweawer commented Jan 20, 2025

What

Change Kraken setting to enforce TLS in the communication between services.

Why

We want to onboard Kraken to secure proxy or use mTLS, this PR, will allow enforcing certificates verification if the certificates are provided in the request, and Kraken services are already providing them in our infra.

How

Remove optional verification between services.

Tested in the devzone.

Things we might want to consider

Have a config to setting for this changes.

@hweawer hweawer self-assigned this Jan 20, 2025
@hweawer hweawer marked this pull request as draft January 20, 2025 10:06
@hweawer hweawer marked this pull request as ready for review January 20, 2025 10:54
@gkeesh7
Copy link
Collaborator

gkeesh7 commented Jan 20, 2025

Things we might want to consider
Have a config to setting for this changes.

That's a great idea! Could you incorporate a config setting for this change into this PR itself?

@@ -31,12 +31,6 @@ var _nameToDefaultTemplate = map[string]string{
const DefaultClientVerification = `
ssl_verify_client optional;
set $required_verified_client 1;
if ($scheme = http) {
Copy link
Collaborator

@gkeesh7 gkeesh7 Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned it would be better if we can drive it via config.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the benefits of using config for this? The only benefit I see is if someone wants to use Kraken with HTTP instead of HTTPS. But I believe we should discuss internally whether we want to support HTTP communication for the future. We've already partially discussed this here: #379

@@ -72,7 +72,7 @@ func (c *HTTPClient) GetTag(tag string) (core.Digest, error) {
func (c *HTTPClient) Download(namespace string, d core.Digest) (io.ReadCloser, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't blob downloads from Agents be unauthenticated ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why they should? I thought that we should encrypt all the traffic, isn't it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All traffic should be authenticated and encrypted. The only exception is that requests from localhost should not be required to authenticate themselves, i.e. only TLS will be enforced instead of mTLS.

However, I wonder if hardcoding the HTTP/HTTPS protocol like this makes sense. I'm not sure about this but I believe Kraken supports falling back to HTTP if https doesn't work and people outside of Uber might use this feature. This means that if we hardcode the HTTPS protocol, the new version might not work for them.
Check this comment and piece of code for more context:

// Retry without tls. During migration there would be a time when the

@@ -72,7 +72,7 @@ func (c *HTTPClient) GetTag(tag string) (core.Digest, error) {
func (c *HTTPClient) Download(namespace string, d core.Digest) (io.ReadCloser, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All traffic should be authenticated and encrypted. The only exception is that requests from localhost should not be required to authenticate themselves, i.e. only TLS will be enforced instead of mTLS.

However, I wonder if hardcoding the HTTP/HTTPS protocol like this makes sense. I'm not sure about this but I believe Kraken supports falling back to HTTP if https doesn't work and people outside of Uber might use this feature. This means that if we hardcode the HTTPS protocol, the new version might not work for them.
Check this comment and piece of code for more context:

// Retry without tls. During migration there would be a time when the

@@ -31,12 +31,6 @@ var _nameToDefaultTemplate = map[string]string{
const DefaultClientVerification = `
ssl_verify_client optional;
set $required_verified_client 1;
if ($scheme = http) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the benefits of using config for this? The only benefit I see is if someone wants to use Kraken with HTTP instead of HTTPS. But I believe we should discuss internally whether we want to support HTTP communication for the future. We've already partially discussed this here: #379

@@ -48,7 +48,7 @@ func New(addr string) *HTTPClient {
// GetTag resolves tag into a digest. Returns ErrTagNotFound if the tag does
// not exist.
func (c *HTTPClient) GetTag(tag string) (core.Digest, error) {
resp, err := httputil.Get(fmt.Sprintf("http://%s/tags/%s", c.addr, url.PathEscape(tag)))
resp, err := httputil.Get(fmt.Sprintf("https://%s/tags/%s", c.addr, url.PathEscape(tag)))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have many hardcoded http requests in the code (search for http:// in the codebase). Why do we need to change this one to https and not the others?

@hweawer hweawer marked this pull request as draft February 3, 2025 12:03
@hweawer hweawer closed this Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants