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

secret: add secret provider interface and use it for TlsCertificates #4086

Merged
merged 4 commits into from
Aug 11, 2018

Conversation

lizan
Copy link
Member

@lizan lizan commented Aug 8, 2018

Signed-off-by: Lizan Zhou zlizan@google.com

Description:
Add secret provider interface which is part of DynamicTlsCertificateProvider interface proposed in #3700. Make static and inline TlsCertificate utilize it.

Risk Level: Low
Testing: unit test, integration test
Docs Changes: N/A
Release Notes: N/A

Signed-off-by: Lizan Zhou <zlizan@google.com>
@lizan lizan requested a review from PiotrSikora August 8, 2018 10:12
@lizan
Copy link
Member Author

lizan commented Aug 8, 2018

cc @JimmyCYJ @qiwzhang

Signed-off-by: Lizan Zhou <zlizan@google.com>
@@ -60,6 +60,7 @@ class ContextConfig {
*/
virtual const std::string& certificateRevocationListPath() const PURE;

// TODO(lizan): consider refactor 4 methods below to Ssl::TlsCertificateConfig
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 for this change.

Copy link
Member Author

Choose a reason for hiding this comment

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

FWIW: lizan/envoy@static_secret_provider...tls_certificate_config , I prefer to have this change in a follow up PRs, but if reviewers prefer in same PR, I will add a commit.

qiwzhang
qiwzhang previously approved these changes Aug 8, 2018
Copy link
Contributor

@qiwzhang qiwzhang left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@JimmyCYJ JimmyCYJ left a comment

Choose a reason for hiding this comment

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

LGTM

JimmyCYJ
JimmyCYJ previously approved these changes Aug 8, 2018
@lizan
Copy link
Member Author

lizan commented Aug 8, 2018

@ggreenway and/or @mattklein123, PTAL. For a non-Google review.

@mattklein123
Copy link
Member

Yes I will look. Please assign me as a reviewer on all SDS PRs.

@mattklein123 mattklein123 self-assigned this Aug 8, 2018
Copy link
Contributor

@PiotrSikora PiotrSikora left a comment

Choose a reason for hiding this comment

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

I'm probably missing something, but what's the reason for having TlsCertificateConfigProvider, which is effectively a wrapper around TlsCertificateConfig?

I do agree that we need to move all certificate-specific fields, regardless of whether they were read from file, inlined or fetched via SDS, into a common object, which is why I proposed TlsCertificateConfig a few SDS PRs ago, but I don't see the reason for another layer of misdirection?

* @param tls_certificate the protobuf config of the TLS certificate.
* @return a TlsCertificateConfigProviderSharedPtr created from tls_certificate.
*/
virtual TlsCertificateConfigProviderSharedPtr createInlineTlsCertificateProvider(
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need this? And couldn't this be static? It doesn't seem to be modifying or requiring SecretManager at all.

Copy link
Member Author

Choose a reason for hiding this comment

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

It could be static with current implementation since I wanted to keep this PR as a refactor. Though secret_manager might do more in future, (e.g. returning same provider if config is exactly same), and/or track all secrets for dump config like rds does.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry what is the different between an inline secret and a static secret? I'm confused.

Copy link
Contributor

Choose a reason for hiding this comment

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

inline secret is the secret directly embedded in the config. static secrets are specified in the static_resources, the config only has a name to point to it.

Copy link
Member

Choose a reason for hiding this comment

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

OK then I guess I have the same question as @PiotrSikora. Why isn't this static?

Copy link
Contributor

@qiwzhang qiwzhang Aug 10, 2018

Choose a reason for hiding this comment

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

My understanding is: inline is the legacy way of configuring ssl cert. statis secrets are only added when SDS works started to share secrets used in many places. By removing inline, it may break existing users.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not saying to remove inline, I think that will always be there. My question is why isn't inline just a static secret?

Copy link
Member Author

Choose a reason for hiding this comment

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

@mattklein123 IIUC @PiotrSikora asks why not making the C++ method static, your question is to merge inline secret and static secret.
Static secrets can be only registered via static_resources in bootstrap.proto, looked up by name, owned by secret manager. Inline secrets are in each tls_context, have no name, in future, secret manager may track more than current implementation. They have different lifecycles.

Copy link
Member

Choose a reason for hiding this comment

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

Ah I see. OK.

@lizan
Copy link
Member Author

lizan commented Aug 9, 2018

I'm probably missing something, but what's the reason for having TlsCertificateConfigProvider, which is effectively a wrapper around TlsCertificateConfig?

It is to extract the callbacks for dynamic secret, which will swap the holding TlsCertificateConfigPtr, like this: https://github.com/envoyproxy/envoy/pull/3700/files#diff-93a68bfee9eaf7ed295925ab50201db8R16

namespace Secret {

/**
* A secret provider for each kind of secrets.
Copy link
Member

Choose a reason for hiding this comment

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

nit: s/secrets/secret

@@ -19,7 +21,7 @@ std::string read(const envoy::api::v2::core::DataSource& source, bool allow_empt
* @param source data source.
* @return std::string path to DataSource if a filename, otherwise an empty string.
Copy link
Member

Choose a reason for hiding this comment

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

update

* @param tls_certificate the protobuf config of the TLS certificate.
* @return a TlsCertificateConfigProviderSharedPtr created from tls_certificate.
*/
virtual TlsCertificateConfigProviderSharedPtr createInlineTlsCertificateProvider(
Copy link
Member

Choose a reason for hiding this comment

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

Sorry what is the different between an inline secret and a static secret? I'm confused.

Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

LGTM after typos.

@lizan lizan dismissed stale reviews from JimmyCYJ and qiwzhang via 85339f8 August 10, 2018 20:46
@lizan lizan merged commit 98037ed into envoyproxy:master Aug 11, 2018
@lizan lizan deleted the static_secret_provider branch August 11, 2018 20:53
snowp added a commit to snowp/envoy that referenced this pull request Aug 14, 2018
* origin/master: (38 commits)
  test: add tests for corner-cases around sending requests before run() starts or after run() ends. (envoyproxy#4114)
  perf: reduce the memory usage of LC Trie construction (envoyproxy#4117)
  test: moving redundant code in websocket_integration_test to utilities (envoyproxy#4127)
  test: make YamlLoadFromStringFail less picky about error msg. (envoyproxy#4141)
  rbac: add rbac network filter. (envoyproxy#4083)
  fuzz: route lookup and header finalization fuzzer. (envoyproxy#4116)
  Set content-type and content-length (envoyproxy#4113)
  fault: use FractionalPercent for percent (envoyproxy#3978)
  test: Fix inverted exact match logic in IntegrationTcpClient::waitForData() (envoyproxy#4134)
  Added cluster_name to load assignment config for static cluster (envoyproxy#4123)
  ssl: refactor ContextConfig to use TlsCertificateConfig (envoyproxy#4115)
  syscall: refactor OsSysCalls for deeper errno latching (envoyproxy#4111)
  thrift_proxy: fix oneway bugs (envoyproxy#4025)
  Do not crash when converting YAML to JSON fails (envoyproxy#4110)
  config: allow unknown fields flag (take 2) (envoyproxy#4096)
  Use a jittered backoff strategy for handling HdsDelegate stream/connection failures (envoyproxy#4108)
  bazel: use GCS remote cache (envoyproxy#4050)
  Add thread local cache of overload action states (envoyproxy#4090)
  Added TCP healthcheck capabilities to the HdsDelegate (envoyproxy#4079)
  secret: add secret provider interface and use it for TlsCertificates (envoyproxy#4086)
  ...

Signed-off-by: Snow Pettersen <snowp@squareup.com>
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

5 participants