Users want a fully declarative policy mechanism

[kflynn]

Managing policy is challenging. By definition, it's such a large, open-ended problem space that we cannot fully specify all possible policies. This means that must create extension mechanisms, which are in turn affected by the existing constraints on Kubernetes API design.

At the same time though, we need to ensure any mechanism we add for policy is broadly and easily usable by end users, and we should be willing to inconvenience implementers in order to gain clarity and usability for users. A critical aspect here is that we need to make sure that policy mechanisms fit into the fully-declarative model on which Kubernetes is built; policy mechanisms that don't line up with that model will cause a lot of usability headaches for anyone trying to use them.

[robscott]

@kflynn Just to clarify, are you stating that the current policy attachment model is not declarative? If so, it would be helpful if you could describe the gaps you're seeing.

[brianehlert]

Personally, the Policy attach should be on the Parent side, not on the Policy side. (regardless of the title)
I think Flynn's story outlines the inherent problems in having it be Policy side.
Having the attach parent side means the owner of the Policy gets to own the Policy. And the owner of the Route gets to attach or detach and thus control the impact.
As long as the Policy creator has a way to attest that the Policy is indeed applied, then I think the spirit is met.

[costinm]

Not sure I understand the goals - all CRDs are 'declarative'.

The fundamental problem with policies is IMO access control ( to control who is allowed to apply policies) and mutual consent if namespaces boundaries are crossed. I don't think we have any major problem here.

I mentioned before: the biggest missing piece (IMO) is a mechanism to identify 'critical' policies vs 'optional' policies.
Example - Authz policies would be critical - telemetry options optional. Implementations need to be able to detect
the policies attached ( which is not easy since they can be any CRD ) and if they are critical, and refuse to serve if it can't
satisfy one of the critical policies. Similar mechanism exists in certificates for example for the extensions.
I know the trend of the year is to only use CRDs and not annotations or labels - but this is a perfect example where
labels and a common group for all policies could help. An implementation may get RBAC permissions for the group,
query the resources ( by checking what CRDs are installed ), and use the labels to identify attachment - without having to understand and be configured for each vendor's CRD.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kflynn]

This should've been long since closed.