User management

You manage users in the Cloudfleet Console on the user management page.

Invite team members to your organization by entering their email addresses. Assign roles to users to control their access to your organization’s resources. For centralized identity management, connect your corporate identity provider through Single Sign-On (SSO). Accounts that sign in with a password can use two-factor authentication (2FA). For the setup Cloudfleet recommends, see Recommended security setup.

CFKE security model and Cloudfleet roles

Cloudfleet provides two primitive roles to manage access to your organization’s resources:

• Administrator
• User

Administrators have full access to all resources in your organization. They can create and manage clusters, manage users, manage API tokens, and manage billing.

Users have limited access to your organization’s resources. They can sign in to Cloudfleet and connect to clusters, but they cannot manage clusters, users, API tokens, or billing.

CFKE fully supports Kubernetes RBAC. Today, when you grant a user the Administrator or User role on Cloudfleet, CFKE maps it to the Kubernetes cluster-admin or view role, respectively. The view role gives every user read-only access to all Namespaces in every cluster of your organization.

Cloudfleet is moving away from this baseline. In the new model, the User role only lets a person sign in to Cloudfleet and authenticate to your clusters. A user has no permissions in any cluster or Namespace until you grant them in Kubernetes RBAC. The Administrator role keeps its cluster-admin mapping. To switch your organization to the new model now, contact support.

In both models, you elevate a user’s permissions by granting additional roles in Kubernetes RBAC. If you use SSO, bind roles to the groups from your identity provider, as described in Use your groups for access control.

Granting additional permissions with Kubernetes RBAC

To grant a user permissions in a specific Namespace, create a RoleBinding that maps their identity to a Kubernetes role.

For example, to grant a user edit permissions in the development namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-edit-binding
  namespace: development
subjects:
- kind: User
  name: [email protected]  # The user's email address
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit  # Built-in Kubernetes role with read/write access
  apiGroup: rbac.authorization.k8s.io

To grant the same permissions to all users in your organization, bind the User group. CFKE maps each Cloudfleet role to a Kubernetes group of the same name. Administrators also carry the User role, so the User group covers every member of your organization:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-edit-binding
  namespace: development
subjects:
- kind: Group
  name: User  # All members of your Cloudfleet organization
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Warning: Do not bind roles to system:authenticated to target your organization. Kubernetes adds every authenticated identity to that group, including GitHub Actions and GitLab CI identities that you have granted any role. Those CI identities would inherit the binding too.

Common built-in ClusterRoles you can reference:

• view: Read-only access to most resources
• edit: Read/write access to most resources in a namespace
• admin: Full access within a namespace, including RBAC
• cluster-admin: Full access to all resources (use with caution)

For more details on Kubernetes RBAC, see the Kubernetes RBAC documentation.

Invite a user

1. Go to the user management page.
2. Click the Invite button.
3. Enter the email address of the user you want to invite.
4. Click the Invite button.

The user receives an email invitation to join your organization. After they accept the invitation, they can access your organization’s resources. New users get the User role by default.