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.

Added:

• 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]

Background

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.

Design

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)

Background

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

Design

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

e.x.

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

Background

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.

Design

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

e.x.:

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