-
Notifications
You must be signed in to change notification settings - Fork 10
Setting up the CLI backend app
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.
-
Install the Kabanero operator. See https://kabanero.io/docs/ref/general/#scripted-kabanero-foundation-setup.html
-
Create or choose a Github Organization for which you are an Owner. Your Kabanero Instance will be scoped to this 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
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.
- The name of
-
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
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
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
9/8/2019 - I think this next part still needs to be done in the Kabanero Operator. Need to confirm.
- If using a private GitHub server, use a config map to set the environment variable github_api_url. For example, github_api_url=https://api.github.mycompany.com By default the github_api_url is https://api.github.com