Skip to content
This repository has been archived by the owner on Jul 28, 2023. It is now read-only.

Setting up the CLI backend app

mchenggit edited this page Apr 23, 2021 · 50 revisions

Note: the official repository has moved to: https://github.com/icp4apps/kabanero-security

In order to login and use the Kabanero CLI you must create a Github Team, add team members, and map the team to your Kabanero Instance.

Before you Begin:

Procedure to set up the Kabanero command-line-service:

1. Set up GitHub teams for your organization

  • A user must be a member of at least one github team, or login will fail.
  • Setup a github team in your organization as described here

2. Map GitHub teams to security groups.

9/8/2019 - I think this next part is already done in the Kabanero Operator. Need to confirm.

Note: this is a temporary workaround. In particular, rather than configmap it is likely that the github team will be added to the Kabanero Operator config.

  • Define environment variables in this format:

    • The name of teamsInGroup_admin (admin is the role name protecting all Kabanero microservice endpoints). teamsInGroup_admin is a required key name in the configMap, it should not be altered.
    • A value of a comma separated list of teams.
  • Be sure to use the fully qualified name, i.e. "github-team-name@org"

  • Example: For the team myproject-admins@org to be in the admin and operator groups, and the team "test-team@org" to be in the operator group, specify two environment variables:

    teamsInGroup_admin="myproject-admins@org" (future: teamsInGroup_operators="test-team@org,myproject-admins@org")

  • Define the environment variables using a config map, for example:

    oc create configmap role-config --from-literal=teamsInGroup_admin=myproject-admins@org

3. Configure AES Encryption key:

9/8/2019 - I think this next part is already done automatically in the Kabanero Operator. Need to confirm.

  • create a kube secret to hold the key

    `oc create secret aesencryptionkey --from-literal=AESEncryptionKey=my_secret_key`
    
    (note: replace my_secret_key with a randomly generated unique value)
    
  • This key is used to encrypt github personal access tokens and passwords and to sign the JWT's.

  • Currently the command-line-service pod generates a random secret at startup. If the pod is restarted the secret will change and all encrypted artifacts will be invalid.

  • note: see issue for follow-on work: https://github.com/kabanero-io/kabanero-operator/issues/136

4. Update deployment.yaml for Kabanero instance

9/8/2019 - I think this next part is already done in the Kabanero Operator. Need to confirm.

Note: this is a temporary workaround. In particular, rather than configmap it is likely that the github team will be added to the Kabanero Operator config. If you follow the approach below (configmap) it is likely that at pod restart the Kabanero Operator will reset back to previous config and wipe out your changes

  • edit deployment.yaml to include it, two methods (modify yaml as per below and apply):

    • OKD console->applications->deployments->Kab microservice instance->configuration tab->actions->Edit yaml, edit and save
    • kubectl get pods kab_pod_instance -o yaml (modify and apply)
  • to consume the secret and the configmap for group mapping.

      spec:
        containers:
        - env:
          - name: AESEncryptionKey
            valueFrom:
              secretKeyRef:
                key: AESEncryptionKey
                name: aesencryptionkey
          - name: teamsInGroup_admin
            valueFrom:
              configMapKeyRef:
                key: teamsInGroup_admin
                name: role-config
          - name: teamsInGroup_operators
            valueFrom:
              configMapKeyRef:
                key: teamsInGroup_operators
                name: role-config
    

5. Customize the GitHub Server API URL

9/8/2019 - I think this next part still needs to be done in the Kabanero Operator. Need to confirm.