Service AccountsCopy Anchor Link

Open Service Accounts under Security & Audit in the Console sidebar. A service account belongs to one Workspace and has its own permissions and credentials. Use it for automated workloads independently of a team member’s login.

Create and grant accessCopy Anchor Link

1. Select the Workspace. Its service-account address suffix is fixed automatically; no Workspace ID setup is required.
2. Open Service Accounts and select Create service account to open the right-side panel. Enter a Service account ID such as deploy-bot and a descriptive Name. The fixed suffix is shown below the ID. Select Create service account in the panel to save. If creation fails, your inputs remain available for retry.
3. Select Edit account, check the allowed projects.
4. Save changes. The account receives the roles/featureControl.configurationReader role in each selected project.
5. Open Access tokens, give the token a name and expiration, then copy it once into your server's secret store.

Service account IDs accept 3–30 lowercase letters, numbers or hyphens, starting with a letter and ending with a letter or number. The resulting address is permanent. Workspace IDs cannot be chosen or changed in Console. You can edit the display name; neither renaming the Workspace nor editing the account changes its address. Deleted account addresses cannot be reused.

These addresses identify accounts; they do not receive email and cannot replace an access token. Accounts belong to the Workspace. For a project-specific workload, grant access to just that project.

Access covers every current and future Feature Control environment in each selected project. An empty project list denies access. Clear project access removes all selections. Every token uses the account's current grants. Use separate accounts for workloads needing different permissions. Only the configuration-reader role is currently supported.

Managing accounts requires service_accounts.manage; viewing them requires service_accounts.read; issuing and revoking tokens requires service_accounts.tokens.manage. Granting project access and issuing scoped tokens also requires project.iam.manage and feature_flags.configurations.read in every selected project. Workspace Owner and Admin include these permissions.

Supported accessCopy Anchor Link

Service-account tokens support authorized Feature Control configuration retrieval. They do not authenticate application SDKs, the RDC CLI, Registry, interactive Console, Envault or resource lifecycle APIs. For application integration, use SDK Endpoint and Create SDK token in Feature Control. Contact support for platform integration requirements.

Rotate and revokeCopy Anchor Link

Issue a replacement token, update the workload and verify retrieval before revoking the old token. Up to ten unexpired, unrevoked tokens can coexist per account. Expiration must be between 1 and 365 days. Token secrets are shown once; save the token securely before closing the panel.

Disabling an account blocks all its tokens until re-enabled. Deletion revokes all tokens and removes grants permanently. Audit history remains available. Changes apply on subsequent requests; completed responses cannot be recalled.

A Workspace supports up to 100 non-deleted accounts and each account can allow up to 100 projects. If another administrator changes the account while you are editing, reopen the editor before saving again. Token history shows the most recent 100 entries.