[Proposal] Kubecon Demo that shows infrastructure flagging with CUE/Signed images

[AlexsJones]

I believe we need to have some really good examples of feature-flagging on both the client/developer side and also used in infrastructure scenarios.

I propose that we combine several key technologies to build a very compelling demo.

• Open feature operator + flagD
• Sigstore/cosign
• CUE

The following proposal is to build a demo image admission application that could potentially be spun out into a real project eventually. The tie into OpenFeature is that it would read its flag configuration to decide whether the image signing validator is turned on or off.

Comments welcome.

Work involved:

• Write a CUE based ievaluator
• Extend Openfeature operator to read CUE based configuration
• Write the demo image admission controller

End-user takeaways:

• Featureflags can be used at the infrastructure level
• OpenFeature operator and FlagD allow you to build against them with no real work required to integrate ( evaluator included ).

[beeme1mr]

Hey Alex, thanks for putting together the proposal! I think CUE would be a perfect fit for simplifying flag creation and validation but I'm not sure how it would be used in the ievaluator. Could you elaborate on that part of the proposal?

[toddbaert]

I think this is a cool idea, and I like the idea of the CUE flag definition.

Will you use json-logic for targeting/rules? Or not implement targeting/rules? You could try CEL if it's of interest to you... I'm not sure if you can do decisions or general rule engines in CUE.

[toddbaert]

Hey Alex, thanks for putting together the proposal! I think CUE would be a perfect fit for simplifying flag creation and validation but I'm not sure how it would be used in the ievaluator. Could you elaborate on that part of the proposal?

The ievaluator doesn't just evaluate rules, but also flags. It understands the flag structure. It's the "brain" that understands the flag definition. All the other interfaces are completely unaware of that.

[beeme1mr]

The ievaluator doesn't just evaluate rules, but also flags. It understands the flag structure. It's the "brain" that understands the flag definition. All the other interfaces are completely unaware of that.

Got it, that makes sense. Validation using CUE is extremely powerful and easier to write than JSON schema (in my opinion).

Will you use json-logic for targeting/rules? Or not implement targeting/rules? You could try CEL if it's of interest to you... I'm not sure if you can do decisions or general rule engines in CUE.

I would prefer to not introduce another rules engine.

[toddbaert]

I would prefer to not introduce another rules engine.

I don't mind so much, but I guess we could keep the rules in json-logic in that case, or not support them.

[AlexsJones]

I was thinking of using CUE as a superset for the user to express themselves and when it's brought into flagd it gets interpreted down into pure json and plays ball with the existing engine.

[dlorenc]

Just stumbled on this and wanted to point out the sigstore policy-controller, which uses Cue to define policy for which images to admit. I'd love to collaborate and see if we can combine these demos :)

https://github.com/sigstore/policy-controller

[AlexsJones]

Thanks @dlorenc I wonder if we could use the existing policy controller and interact with it somehow to turn it on or off.

As you can see in this issue the aim is to show evidence and "wow" factor of flagging infrastructure features. Is there an API or Custom resource the policy controller uses to signal its behaviour? ( If not we could indeed collaborate )

I took a quick look but would love to know what you think!

[AlexsJones]

I had the chance to take a look at the controller and it looks like for us to integrate with Open Feature. The easiest way seems to be for us to create a service that either creates or deletes Policy resources

https://github.com/sigstore/policy-controller/blob/main/pkg/webhook/validator.go#L178

[AlexsJones]

https://github.com/open-feature/research/blob/main/002-OFEP-kubecon-demo.md

Keeping this open a little as we have some folks in this thread who are not familiar that we have moved to a pull-request based review process for research

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in next 60 days.

[github-actions[bot]]

This issue was closed automatically because there has not been any activity for 90 days. You can reopen the issue if you would like to continue to work on it.