Authorize all developers to have read access to your clusters
We want to ensure every developer in our GitHub organization has access to our Kubernetes clusters.
First, set up an GitHub as an identity provider. Start by creating a new OAuth Application in our GitHub Organization by filling out this form.
Once we create this application we are going to see something like this:
In Kommander UI, choose Global in the header drop-down and then select Administration > Identity Providers in the sidebar. Select the Identity Providers tab and click the Add Identity Provider button. Ensure GitHub is selected as the identity provider type, and copy the Client ID and Client Secret values into the form. Press Save to create your Identity Provider.
We configured the identity provider to load all groups, so now, map these groups to Kubernetes groups. In Kommander UI, choose Global in the header drop-down and then select Administration > Identity Providers in the sidebar. Select the Groups tab and click the Create Group button. Give your group a descriptive name and add the groups from your GitHub provider under Identity Provider Groups. Click Save to create the group. It will be created on the management cluster and federated to all target clusters, and describes the developers of our organization.
For this group to have an effect, connect it to a role, so first create a role that allows us to view every resource. In Kommander UI, choose Global in the header drop-down and then select Administration > Access Control in the sidebar. Select the Cluster Roles tab and click the Create Role button. For a read-only role, click + Add Rule, select the get, list, and watch verbs, and select All resource types in the Resources input.
Now that we have everything we can assign the “Read Everything” role to the developers group. In Kommander UI, choose Global in the header drop-down and then select Administration > Access Control in the sidebar. Select the Cluster Policies tab and click the Add or remove roles button for your group.
Lastly, follow the example in the Access Control documentation to grant users access to the opsportal and Kommander routes on your cluster.
When we check our attached clusters and login as a user from our matched groups we can see every resource, but neither delete or edit them, just as we intended it to be.