Check out what's in the latest release of Kabanero Learn More

Configuring Kabanero CLI service authorization

You can modify your Kabanero custom resource (CR) instance to provide authorization to the teams in GitHub that will administer the application stacks. If you do not already have a team defined, see Creating a team.

Authorization setup (optional): If the container registry containing the stack images is protected, see Step 2 of the Configuring governance policy for stacks page.

Authorization setup (optional): If accessing repositories on GitHub Enterprise, see Steps 1 and 2 of the Specifying credentials to access GitHub Enterprise resources page. Step 4 explains how to set up the Kabanero Custom Resource document to point to your GHE repositories.

Providing login authorization to the CLI service (required):

  • The Spec.Github.organization attribute should be set to the organization hosting the stacks in the remote GitHub repository. In the previous example, the organization name is my_org.

  • The Spec.Github.teams attribute should be set to a yaml list of GitHub teams in the remote GitHub repository, whose members can administer the stack using the stack management CLI.

  • The Spec.Github.apiUrl attribute should be set to the API URL for the remote GitHub repository being used. For example, the API URL for is

A modified Kabanero CR instance for an application stack repository located in the my_org organization of the GitHub repository using release 0.6.0 of stacks might look like this:

kind: Kabanero
  name: kabanero
  namespace: kabanero
    - name: custom
    organization: my_org
      - stack-admins
      - admins
    ## github: (public)
    ## ghe:
    ## refer to GitHub or GHE documentation for more info on authentication endpoints

Note: Avoid using the OpenShift Console to edit the Kabanero CR instance. The console may change the apiVersion of the Kabanero CR instance from v1alpha2 to v1alpha1. There is a description of the issue here.

Edit This Page