search

solo-io / gloo

The Feature-rich, Kubernetes-native, Next-Generation API Gateway Built on Envoy
https://docs.solo.io/
Apache License 2.0
4.02k stars 433 forks source link

Gloo Enterprise API Detection/Warning #6495

Open sam-heilbron opened 2 years ago

sam-heilbron commented 2 years ago

Version

1.12.x (beta)

Is your feature request related to a problem? Please describe.

At times, it is unclear whether a feature is available in open source or enterprise (or both).

Describe the solution you'd like

The Gloo open source and enterprise API is defined in the open source project. We want to provide a simple solution to:

  1. Identify an API as enterprise only
  2. Document that behavior in our external documentation
  3. Notify users if they incorrectly opt into an enterprise feature while using the open source project

Existing Solution

We currently use the following manual processes to identify an API as enterprise-only:

  1. Comment on the API proto definition, since those comments are used to auto-generate external facing docs (https://github.com/solo-io/gloo/blob/0eec04dc0486976fc89bac314b0fd9eccd5261f5/projects/gloo/api/v1/settings.proto#L359)
  2. Add the validation to our enterprise-warning plugin which is responsible for parsing user defined APIs and identifying enterprise-only functionality (https://github.com/solo-io/gloo/blob/0eec04dc0486976fc89bac314b0fd9eccd5261f5/projects/gloo/pkg/plugins/enterprise_warning/plugin.go#L5)
  3. If the API affects our rate-limit and ext-auth translations, extend the extension syncers as well, to include this field (https://github.com/solo-io/gloo/blob/0eec04dc0486976fc89bac314b0fd9eccd5261f5/projects/gloo/pkg/syncer/extauth/extauth_translator_syncer.go#L57)

Existing Solution Drawbacks

This solution requires changes in a number of places, all of which must be known by the developer implementing the feature.

Proposed Solution

Add an enterprise proto message option, and build a plugin that relies on the existence of that field to identify enterprise configuration used in an open source installation.

I think this work can be approach in the following steps:

  1. Write the plugin that is responsible for parsing proto messages and returning an error if a field that is designated as enterprise-only has configuration associated with it. This plugin would only be injected into the open source plugin registry. We could even write this plugin against existing message options to identify how easy/feasible this is
  2. Assuming part 1 was successfully, expose a new enterprise-only message option
  3. Work with the docs team to identify the appropriate way to consume this field in our docs
  4. Remove our enterprise extension translators (https://github.com/solo-io/gloo/blob/0eec04dc0486976fc89bac314b0fd9eccd5261f5/projects/gloo/pkg/syncer/extauth/extauth_translator_syncer.go#L57). These are overridden by the enterprise extensions, and are just responsible for logging errors that our plugin in step 1 should complete. We should confirm that removing these syncer implementations still allows us to log warnings for enterprise usage.

Describe alternatives you've considered

No response

Additional Context

No response

github-actions[bot] commented 4 weeks ago

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.