There are two user roles in Octopod:
- user
- admin
| role | managing deployments | viewing deployment logs |
|---|---|---|
| user | ✅ | ❌ |
| admin | ✅ | ✅ |
Web UI users have the user role.
octo CLI users have the admin role.
There is currently no way to give someone access to octo CLI without giving them the admin role since authentication is not done through OAuth.
Octopod Server is deployed in the octopod Kubernetes namespace. Deployments are deployed in the deployments namespace.
Octopod Server uses the octopod Service Account.
Octopod needs sufficient permissions to run Helm inside Kubernetes and create all resources described in the Helm chart it is installing. Thus permissions are quite extensive.
RBAC rules to describe permissions needed are added automatically by the Octopod Helm Chart.
Authentication between the Web UI and Octopod Server is done through Basic Auth. The Bearer token is read by the Web UI after the page is loaded as part of the config. By default, everything, including the config, can be accessed without any authentication. For ways of mitigating this please see the next section.
The Web UI on its own does not have any authentication whatsoever, meaning that anyone can open it and manage your deployments. Luckily, Kubernetes can be configured to authenticate users before they get access to the Web UI. It can be set up to authenticate users through Ingress which supports external authentication services. You can set up OAuth2 Proxy in your cluster to support numerous OAuth services. For example, if you use GitHub, you can set up OAuth2 Proxy to use GitHub to automatically grant users access to Octopod when you add them to your organization in GitHub.
Authentication between octo CLI and Octopod Server is done through special token which is generated automatically or specified by user in octopod.cliAuthSecret parameter, as described here.
Star the project of you like it
