Operator Permission Advisor
Operator Permissions Advisor is a CLI tool that will take a catalog image and statically parse it to determine what permissions an Operator will request of OLM during an install. The permissions are aggregated from the following sources:
- The CSV
manifestsdirectory of each bundle in the desired install channel
This tool uses the standardized operator-registry
actions library github.com/operator-framework/operator-registry/alpha/action to query the catalog.
./operator-permission-advisor static --help Statically check the catalog for permission information Usage: operator-permission-advisor static [flags] Flags: -c, --catalog string catalog source image repo -s, --channel string channel to check for permissions in -R, --clusterRole string location to save the aggregated clusterRole to (default "STDOUT") -h, --help help for static -o, --operator string operator package to check for permissions in -r, --role string location to save the aggregated role to (default "STDOUT")
Implements issue #6 heads of channels
This implements issue https://github.com/IBM/operator-permission-advisor/issues/6 to only look at heads of channels when determining the role and cluster role file.
--aggregate | -aflag for toggling the head of channel functionality from the front end
Signed-off-by: nathanbrophy [email protected]
[Enhancement] Update tool to use heads of channels
Currently the tooling will aggregate the permissions across all bundles in the channel specified. This means that old bundles could have unused permissions that are included in the output. We need a way to filter those out and only look at the latest permissions.
Update the front end to do head of channel by default and add a flag to enable aggregation
Something like the above should do the trick.
In the back end we will need to honor this flag and use the built in tooling for the
actionsAPI to grab only the heads of channels. This may require us changing from the bundle API to the Package API
It would be nice to wrapper the call to getting the bundle in a separate function that returns a common interface that can flow into the permission aggregation section after.
Enhancement Proposal [Version Command]
This tooling needs a version flag or command that is dynamically generated from the git release information.
ldflagsgolang build parameter it would be nice to have a version command that relays some useful information on the version information.
Add a new
versioncommand for the tooling.
API / Backend Considerations
We will need to import the git API to dynamically generate some of this information at build time.
versioncommand provides version information from the git repo
[Epic] Dynamic Permission Scanning
It can be hard to understand what permissions are needed in an install of an Operator or an Operand. It would be nice if a tool existed that allowed you to dynamically scan a cluster and then write a report of the permissions used during that scan for a given actor.
This could be implemented as a webhook plugin to the admission control plane. The idea would be to intercept any API call to the Kube API server that originates from one of the specified
actors, record the API request and infer the permissions from it.
clusterRolefrom the audit report