A team is a group of users (team members) and it can be granted access to clusters by creating cluster accounts for the team similar to cluster accounts of users.
Instead of statically assigning users to a team, you can also define "Kubernetes Groups" as team members. This is an advantage if you are using OpenID Connect for authentication because your existing team structure can be easily reflected in Loft without the need to manually replicate team memberships.
Example: Your organization is working with GitHub and has existing teams with different members and access permissions in GitHub. If you configure Loft to use GitHub as OpenID Connect Auth Provider and you create the teams you want to give Kubernetes access in Loft, you can define a group membership for the GitHub team name. The result of this is that all users who are part of the GitHub team will also become a member of the corresponding team in Loft.
The screenshot below shows the group "analytics-team" being added as member of the Analytics Team.
Delete a team using
Deleting a team will also delete all cluster accounts that are owned solely by this team. Deleting these accounts in turn will also delete other related objects such as account quotas and spaces.
Image Pull Secrets
Image pull secrets can be used to automatically login users that are part of a team to specified container image registries as soon as they run
loft login (no locally installed docker needed).
Creating a shared image pull secret is very similar to creating an image pull secret in kubernetes itself:
On your computer, you must authenticate with a registry in order to grant other users or teams access to it:
When prompted, enter your Docker username and password.
The login process creates or updates a
config.json file that holds an authorization token.
The output contains a section similar to this:
Note: If you use a Docker credentials store, you won't see that auth entry but a credsStore entry with the name of the store as value.
With that information you can create a shared loft secret.
Note: The actual name of the shared secret or key name do not matter and can be chosen freely.
Next, you can configure a user or team to use that image pull secret, by editing the
Image Pull Secrets section of the user or team.
Then press 'Update'. If the user will now login, he will also login into the specified container registry:
User or Team need view access
In order for the user to login with an image pull secret, the user or the team need to have access to view the shared secret, otherwise they will not be able to login into the container registry. You can change the access to a shared secret in the
Secrets > YOUR-SECRET > Access tab.