Skip to content
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

feat: Extended Root CA for client TLS connections (#181) #744

Conversation

christian-roggia
Copy link
Contributor

See #706.

.schema/config.schema.json Outdated Show resolved Hide resolved
docs/docs/api-access-rules.md Outdated Show resolved Hide resolved
docs/docs/api-access-rules.md Show resolved Hide resolved
internal/certs/cert_manager.go Show resolved Hide resolved
@aeneasr
Copy link
Member

aeneasr commented Jun 11, 2021

@christian-roggia marking this as a draft because you said it's WIP on slack :)

@aeneasr aeneasr marked this pull request as draft June 11, 2021 10:41
@christian-roggia christian-roggia changed the title feat: Extended Root CA for upstream connections (#181) feat: Extended Root CA for client TLS connections (#181) Jun 15, 2021
@christian-roggia christian-roggia marked this pull request as ready for review June 15, 2021 21:14
@christian-roggia
Copy link
Contributor Author

@aeneasr this PR should be cleaned up and ready for review. I deployed this version to our cluster and works like a charm with self-signed TLS certificates. As soon as this is merged I will open a PR also for the Helm charts.

wraix and others added 16 commits June 20, 2021 16:59
This allows for appending a certificate file to the Root CA without altering the system Root CA. This is useful for allowing self-signed certificates on the upstream connections
This adds support for appending certificates to the Root CA of the proxy process on upstreams. This does not alter the entire system.
* Adds cacheing of UpstreamTransport to avoid excessive IO ops at scale
* Adds configuration option `ca_refresh_frequency` for periodic checks of certificate file changes
* Adds new Upstream Configuration section
@christian-roggia christian-roggia force-pushed the fix_issue_118_trust_selfsigend_certs branch from e49e6b3 to c1110d1 Compare June 20, 2021 15:02
@aeneasr
Copy link
Member

aeneasr commented Jun 21, 2021

Thank you, this looks great! The CI is failing because some files are formatted incorrectly. To format them, run:

$ make format
$ git commit -a -m "styles: format code"
$ git push

Thank you!

@christian-roggia
Copy link
Contributor Author

As I wrote on Slack, I run the command before but I didn't commit the two CHANGELOG files as I didn't touch them and the number of changed lines was huge. Looks like it worked tough now that I committed also those two files, I guess the linter was recently updated?

Thank you anyway for the help!

@aeneasr
Copy link
Member

aeneasr commented Jun 21, 2021

The problem was that I changed something in the CI which pushed an unformatted commit to master. Your PR includes those changes thus had issues in the linter. The issue is resolved in the CI but since then no update was triggered on Ory Oathkeeper.

I'll be reviewing your PR shortly!

@aeneasr aeneasr self-requested a review June 21, 2021 08:55
@aeneasr aeneasr self-assigned this Jun 21, 2021
@aeneasr aeneasr added the feat New feature or request. label Jun 21, 2021
Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

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

Thank you for advancing this! From the documentation and overall implementation this looks very good!

To confirm that everything works as expected I think we definitely need to add some more tests.

"github.com/ory/oathkeeper/driver/configuration"
)

type CertManager struct {
Copy link
Member

Choose a reason for hiding this comment

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

Could you please add some tests to the certmanager? Also, what should we take care of here. For example, test different cert pools? How would this look like on Windows? :)

I haven't worked with x509 cert pools before. We should also generally ensure that:

  1. The cache is used
  2. The cache is invalidated properly
  3. No untrusted certs are being used
  4. The OS cert store is being used appropriately on the different OS'es (could be difficult for mac as we don't have a pipeline for that...)

Comment on lines +260 to +263
serve:
proxy:
client_tls:
trusted_certificates:
Copy link
Member

Choose a reason for hiding this comment

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

If this is used for other upstream services (authenticators, ...) I think it would make sense to have client_tls as a root level config item

Comment on lines +44 to +46
ProxyServeClientTLSTrustedCerts() []string
ProxyServeClientTLSCacheRefreshFrequency() int
ProxyServeClientTLSCacheTimeToLive() time.Duration
Copy link
Member

Choose a reason for hiding this comment

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

If we move the config to the root level we need to change this

Comment on lines +46 to +48
ViperKeyProxyClientTLSTrustedCerts = "serve.proxy.client_tls.trusted_certificates"
ViperKeyProxyClientTLSCacheRefreshFrequency = "serve.proxy.client_tls.cache.refresh_frequency"
ViperKeyProxyClientTLSCacheTimeToLive = "serve.proxy.client_tls.cache.ttl"
Copy link
Member

Choose a reason for hiding this comment

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

If we move the config to the root level we need to change this

tr *http.Transport
}

func NewRoundTripper(cm *CertManager) *RoundTripper {
Copy link
Member

Choose a reason for hiding this comment

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

Some tests would be great here as well

@@ -8,9 +8,11 @@ import (
"github.com/tidwall/gjson"
Copy link
Member

Choose a reason for hiding this comment

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

Could we ensure in all the authenticators that the new TLS config is actually being used by adding tests for that case?

@@ -429,6 +431,61 @@ func TestConfigureBackendURL(t *testing.T) {
}
}

func TestUpstreamAppendCaCertToRootCa(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

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

I think we could make this a generic test helper which could then be used in the different relevant places (authenticators, mutators, proxy, authorizers)

@aeneasr
Copy link
Member

aeneasr commented Jul 5, 2021

Just checking in if you need help with the tests :)

@christian-roggia
Copy link
Contributor Author

I will be updating the configuration path to be at the root level but I will most definitely need help setting up tests!

@aeneasr
Copy link
Member

aeneasr commented Jul 12, 2021

Ok! Ping me when you're ready to work on it :) Meanwhile I will mark it as a draft. That declutters our review backlog :)

Once you're done with your changes and would like someone to review them, mark the PR as ready and request a review from one of the maintainers.

Thank you!

@aeneasr aeneasr marked this pull request as draft July 12, 2021 19:51
@aeneasr
Copy link
Member

aeneasr commented Dec 26, 2021

As there has not been an update in the past 6 month, we'll consider this one stale and I'll close the PR. But please, do not feel discouraged in continuing the work if you have some time, the change is still appreciated! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants