support for private/internal CRDs

[willholley]

We have an operator that implements a public and private API using CRDs. The public API is designed to be user-facing - user's create these custom resources for the operator to act on - and the private API feeds to downstream controllers only and users should generally not need to be aware of them. Think of the public API as a domain-specific shim over a generic set of CRDs/controllers.

Is there any way to differentiate these "internal" CRDs in the ClusterServiceVersion such that users of the operator aren't guided to create them manually?

[ecordell]

Thanks @willholley -

You're not the first to ask for this, and I do think it's important to address this. (see also: #734)

Currently, I'm thinking that we can collect some metadata about CR visibility - we can't prevent you from seeing an API once it's been registered (this is just how CRDs/discovery work), but we can be more careful about how we generate default roles and bindings for consuming CRs.

For UIs, we would expect that they can decide to hide particular CRD apis based on the user's access to read or write them.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[njhale]

but we can be more careful about how we generate default roles and bindings for consuming CRs

So this has been buried for a while, but there's definitely still interest in doing this.

Basically, we're looking at becoming much less opinionated in how we approach operator/user privileges -- putting more control in the hands of operator authors. Here are a few efforts towards making this possible:

• operator descoping
• a strawman for "feature binding"

Closing out -- we'll wrap this into user stories for new features.