The operator permission advisor will statically read a catalog index image and determine an aggregated list of the permissions an Operator needs for an install (dynamic scanning coming soon).

  • By International Business Machines
  • Last update: Apr 22, 2022
  • Comments: 4

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:

  1. The CSV
  2. The manifests directory of each bundle in the desired install channel

This tool uses the standardized operator-registry actions library to query the catalog.


./operator-permission-advisor static --help
Statically check the catalog for permission information

  operator-permission-advisor static [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")



  • 1

    Implements issue #6 heads of channels

    This implements issue to only look at heads of channels when determining the role and cluster role file.


    • Unit test bed for permissions and util package
    • Goreport badge for the README
    • Release makefile target for generating releases
    • --aggregate | -a flag for toggling the head of channel functionality from the front end

    Signed-off-by: nathanbrophy [email protected]

  • 2

    [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

    $ operator-permision-advisor static -c catalog --channel  channel -o package --aggregate 

    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 actions API to grab only the heads of channels. This may require us changing from the bundle API to the Package API

    lp := &ListPackage{ "Catalog image" }
    lpr,_ := lp.Run(context)
    ch := getChannelObjFromPackage(lpr) // this needs to be written
    head := ch.Head() // This should be a bundle

    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.

    Acceptance Criteria

    • [x] e2e test suite created (this needs to happen at some point)
    • [x] Ability to filter the output to just the head of the channel
    • [x] Ability to maintain aggregation feature across the entire channel (not sure if there is a big need for this, but will keep it and deprecate in the futuree)
  • 3

    Enhancement Proposal [Version Command]


    This tooling needs a version flag or command that is dynamically generated from the git release information.


    Using the ldflags golang build parameter it would be nice to have a version command that relays some useful information on the version information.


    type Version struct {
      Semver string
      Build string
      Timestamp string
    $ ./operator-permission-advisor version
    {"version": "1.2.3+<git commit hash ID>", "major": "1", "minor": "2", "patch": "3",  "build": "<git commit has ID>", "timestamp": "01022022.000000"}

    CLI Considerations

    Add a new version command for the tooling.

    API / Backend Considerations

    We will need to import the git API to dynamically generate some of this information at build time.

    Acceptance Criteria

    • [ ] e2e test suite passes with updates
    • [ ] new version command provides version information from the git repo

    Additional Information

  • 4

    [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.


    $ opa dynamic -a admin -a 'system:serviceaccount:test-namespace:my-operator' -d 5m # default is -1 ^C tp exit

    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.


    GET pods # Needs get, list
    GET pod/my-pod # Needs get
    POST pod/my-pod data..... # Needs create 
    etc ......

    Acceptance Criteria

    • [ ] e2e test suite updated/created for the dynamic scan functionality
    • [ ] command that allows dynamic scanning of a cluster
    • [ ] audit report generated for permissions requested during the scan
    • [ ] aggregator to generate a role and/or clusterRole from the audit report