Single Sign-On (SSO)

Cloudfleet supports Single Sign-On (SSO) for organizations. With SSO, your organization’s identity provider authenticates users in Cloudfleet. Cloudfleet supports SAML 2.0 and OIDC as SSO protocols.

Supported identity providers include:

• Microsoft Entra ID
• Google Workspace
• Okta
• JumpCloud

Other identity providers that support SAML 2.0 or OIDC also work.

Email and password sign-in supports two-factor authentication, but it does not offer password policies, user provisioning, or central offboarding. For these controls, connect your corporate identity provider. Cloudfleet provides SSO on all plans, including Basic.

Currently, Cloudfleet Support sets up SSO for your organization. Self-service SSO setup in the Cloudfleet Console is coming soon. If you use Microsoft Entra ID, follow the steps below. For any other identity provider, contact support to start the SSO setup and learn the next steps.

Recommended security setup

Cloudfleet recommends this setup for every production organization. Your identity provider controls who signs in, and Kubernetes RBAC controls what each person can do in a cluster.

1. Connect your corporate identity provider through SSO. Your identity provider then enforces multi-factor authentication, conditional access, and offboarding for every sign-in.
2. Keep two break-glass accounts as the only users with a password. Give both the Administrator role and turn on two-factor authentication. Store the credentials of each account in a separate vault, so one lost credential does not lock you out. Use these accounts only when SSO is unavailable.
3. Add every other team member with the User role. When Cloudfleet Support activates SSO, it disables password sign-in for SSO users, so they can sign in only through your identity provider.
4. Grant cluster permissions with Kubernetes RBAC. Bind roles to the groups from your identity provider instead of to individual users, as described in Use your groups for access control.

Today, the User role also grants read-only view access to every cluster in your organization. Cloudfleet is moving to a model in which the User role only lets a person sign in. In that model, a user has no permissions in any cluster or Namespace until an RBAC binding grants them. To switch your organization to this model now, contact support. See CFKE security model and Cloudfleet roles for details.

Two-factor authentication for password sign-in

Two-factor authentication (2FA) protects the accounts that sign in with an email and password, such as your break-glass accounts. Cloudfleet supports two second factors, and you can register both:

• A time-based one-time password (TOTP) from an authenticator app.
• A FIDO2 security key or passkey.

To turn on 2FA, contact support. Self-service 2FA in the Cloudfleet Console is coming soon.

Users who sign in through SSO do not need Cloudfleet 2FA. Your identity provider applies its own multi-factor authentication policies to every SSO sign-in.

CLI and Terraform sessions

The Cloudfleet CLI, kubectl, the MCP server, and the Terraform provider sign in through the browser once and then stay signed in. A session times out after 30 days without use.

To remove a person’s access, delete the user in Cloudfleet. Disabling the account only in your identity provider does not end an open session.

Custom session timeout

Enterprise customers can set a custom session timeout, for example to require a new sign-in through your identity provider every day. To set it up, contact support.

Set up SSO with Microsoft Entra ID

Connect Microsoft Entra ID (formerly Azure Active Directory) to your Cloudfleet organization so your team signs in with their corporate Microsoft accounts. Your existing Entra policies, such as multi-factor authentication and conditional access, apply to every sign-in.

You register an application in your Entra tenant and send its details to Cloudfleet Support. Cloudfleet Support then activates SSO for your organization.

Before you begin

You need:

• An administrator role in your Microsoft Entra tenant that can register applications and grant admin consent.
• Your Cloudfleet organization ID. You can find it in the Cloudfleet Console or by running cloudfleet organization describe.

Register the application

1. Sign in to the Microsoft Entra admin center.

2. In the left menu, open Entra ID > App registrations and select New registration.

3. Enter a name, for example Cloudfleet.

4. Under Supported account types, keep Single tenant only.

5. Under Redirect URI, choose Web in the Select a platform list and enter the following URL. Replace ORGANIZATION_ID with your Cloudfleet organization ID.

   text Copy

   https://accounts.cloudfleet.ai/realms/ORGANIZATION_ID/broker/microsoft/endpoint

6. Select Register.

The Overview page of the new application shows the Application (client) ID and the Directory (tenant) ID. You need both values later. If the application does not open after you register it, go back to App registrations and select it on the All applications tab.

Create a client secret

1. In the application, open Certificates & secrets and stay on the Client secrets tab.
2. Select New client secret, enter a description, and choose an expiry period.
3. Select Add.
4. Copy the secret from the Value column right away. Entra shows it only once. Do not copy the Secret ID, which is a different value.

Grant admin consent

1. In the application, open API permissions.
2. Confirm that the Microsoft Graph permission User.Read is listed. Entra adds it by default.
3. Select Grant admin consent for followed by your tenant name, and confirm.

Admin consent approves the application for your whole organization. Your users can then sign in to Cloudfleet without approving the application themselves. Sign-in also works in tenants that do not allow users to consent to applications.

Use your groups for access control (optional)

Cloudfleet can read the groups a user belongs to in Microsoft Entra, so you manage access in one place. This is the recommended way to grant cluster permissions. Skip this section if you prefer to manage access per user.

1. In the application, open Token configuration and select Add groups claim.
2. Select Security groups and select Add. Keep Group ID as the token property.

Cloudfleet Support turns on the group translation for your organization when it activates SSO. This is a quick step on the Cloudfleet side. Mention in your support ticket that you added the groups claim.

After that, every group of a user is available in your CFKE clusters as a Kubernetes group. The group name is entra: followed by the group’s Object ID. You find the object ID under Entra ID > Groups. Group membership updates every time the user signs in. After you change a user’s groups in Entra, the user signs out of Cloudfleet and signs in again to receive the new groups.

To check which groups a user has in the cluster, the user runs:

kubectl auth whoami

The output lists the Cloudfleet role groups, such as User, followed by the entra: groups of the user.

A group grants nothing by itself. Bind it to a Kubernetes role with a Group subject. For example, this ClusterRoleBinding makes every member of an Entra group a cluster administrator, while their Cloudfleet role stays User:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-admins
subjects:
- kind: Group
  name: entra:00000000-0000-0000-0000-000000000000
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

To scope access to one Namespace, use a RoleBinding instead, as shown in Granting additional permissions with Kubernetes RBAC. A common pattern is one Entra group per environment and team, each bound to a role in its own Namespace.

The Cloudfleet Console and your clusters use separate permissions. An RBAC binding grants permissions inside a cluster only. It does not let a user manage clusters, users, or billing in the Cloudfleet Console.

You can also let a group decide the Cloudfleet role of its members. Include the object ID of the group and the role it receives, Administrator or User, in your support ticket.

For users who are members of more than 200 groups, Microsoft Entra leaves the groups out of the token. If this applies to your organization:

1. Select Groups assigned to the application instead of Security groups.
2. Assign the relevant groups to the application under Enterprise apps.

Assigning groups to an application requires a paid Microsoft Entra ID plan.

Send the details to Cloudfleet

Open a ticket in the Cloudfleet support center and provide these values:

You can share the client secret directly in the ticket. The support center is a secure channel. After the Cloudfleet team configures the secret, it redacts the secret from the ticket.

Cloudfleet Support activates SSO for your organization and confirms when it is ready.

Sign in with SSO

After activation, a Microsoft Entra button appears on the sign-in page of your organization. Select it and complete the Microsoft sign-in. Cloudfleet then redirects you to the Cloudfleet Console.

The Cloudfleet CLI uses the same sign-in page in the browser. CLI and kubectl access need no extra configuration.

Add users

To sign in with Microsoft Entra, a user needs a Cloudfleet user in your organization. You manage access and roles in Cloudfleet:

1. Invite each team member as described in Invite a user. Use the same email address the user has in Microsoft Entra. Cloudfleet then links the Cloudfleet user to the Entra account.
2. Assign the User role, as described in Recommended security setup. If a group is mapped to a Cloudfleet role, the role from the user’s groups applies instead. See CFKE security model and Cloudfleet roles for what each role can do.

When Cloudfleet Support activates SSO, it disables password sign-in for SSO users. Microsoft Entra is then their only sign-in method. Keep your two break-glass accounts with a password and two-factor authentication for emergencies.

To add many users at once, contact support. Users added this way skip the invitation and sign in with Microsoft Entra right away. Send a list that contains these values for each user:

• Email address
• First and last name
• Cloudfleet role (Administrator or User)
• Microsoft Entra user object ID

Rotate the client secret

Client secrets in Microsoft Entra expire. When the secret expires, Microsoft Entra sign-in to your Cloudfleet organization stops working until a new secret is configured. With self-service SSO setup, coming soon, you will update the secret in the Cloudfleet Console yourself. Until then, Cloudfleet Support configures it.

Before the expiry date:

1. Create a new client secret as described in Create a client secret.
2. Send the new value to Cloudfleet Support in a support ticket.
3. After Support confirms the change, delete the old secret in Entra.