Could we leverage an AST to pinpoint generation of RBAC rules

[cmwylie19]

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

npx pepr build --rbac-mode=scoped will generate RBAC based on the bindings. What happens in the callbacks however is a blind spot. The question is if we can build a parser assuming only the use of KFC to parse through API calls to generate rules that include the callbacks

Describe the solution you'd like

• Given Someone wants precise rbac including API calls during callbacks
• When someone generates rbac with --rbac-mode=scoped
• Then we parse their module and generate the ClusterRoles and Roles based on that. (Doesn't necessarily have to use an AST if there is another way)

Describe alternatives you've considered

not sure, maybe eslint is a starting point to see how they do it

Additional context

Add any other context or screenshots about the feature request here.

[btlghrants]

Pretty much everything I know about ASTs (which, admittedly, is very little) comes from wikipedia but from what it looks like to me, ASTs are mostly applied within a single, known domain -- like, used to parse a single code language into an abstract representation for a compiler to massage into a different more computer-y shape.

Meaning the AST has to understand the syntax of what it's being loaded to rep, right? At least well enough to represent it in full (if abstract) detail, and... that feels pretty different than the challenge we're facing here.

While a module author is required to use ts to write their module, they're not restricted in what they can do with it -- it's really easy for them to escape the scope of what a simple (or any single?) AST could represent. Examples of escaping would include:

• execSyncing out to sh, or bash, or zsh, or whatever shell you fancy Apple people are using now a days, or
• execSyncing out to an "in house" binary / library (that no one alive understands anymore), or
• execSyncing out to a purchased/licensed binary / library (the vendor of which would likely object to investigating), or
• importing a node module that does something similar (by wrapping a curl, or wget, or Invoke-RestMethod, etc.).

All of those scenarios (and I'm sure many more), would lead to the situation where we're somehow trying to interpret what kinds of activity (API call or otherwise) an (essentially) opaque, external process is going to perform, before they perform it, so that we can generate rules about what we'll allow them to do in-cluster. And... I kinda don't think that's gonna be achievable, ASTs or not, given the scope of the challenge.

[btlghrants]

As for other options, things that come to mind include:

• come up with some abstraction (a new module helper or something) that allows them to tell us "I'll be making API calls that look like this: " and then we put something that filters outgoing network traffic based on it, or
• prohibit all outbound network traffic & force them to do use some kind of "pepr supported" option (i.e. a custom curl or something?),
• come up with some sort of "audit mode" helper for module authors that 1) has them run their module while we 2) watch for the network requests they make so we can generate RBAC rules for them to use when out of audit.

^-- all of which would require custom development on our part, make the module author dev flow harder/longer, and/or would restrict freedom of action for a module author pretty severely (at least, compared to what's available now).