# Service Accounts in Kestra Enterprise: CI/CD Auth How to create and manage Service Accounts. ## Service accounts – non-human access
A Service Account represents an **application** that can access Kestra. It is not tied to a specific person and does not have personal information (such as the first name, last name, or email) attached to it. Instead, it only has a name, an optional description, an optional allocation to a group, and a list of Roles that grant it permissions to access specific resources. ## Service accounts vs. users In contrast to regular users, Service Accounts don't have a password and they do not have access to the Kestra UI — they only have a programmatic API access to Kestra. You can think of Service Accounts as bots authenticating with Kestra using an API token. ## Creating a Service Account To create a new service account, go to **Service Accounts** tab on the **IAM** page under the **Tenant** section and click the **Create** button. Fill in the form with the required information, including the name and description and click **Save**: ![service_account_create](./service_account_create.png) Once you have created a service account, you can add a Role that will grant it permissions to specific resources. To do this, switch to the **Access** tab and click the **Add** button and select the role you want to assign to the service account. ![Assign Service Account Role](./service_account_role.png) Finally, you can generate an API token for the service account by clicking the **Create API Token** button in the service account's details. This will generate a token that you can use to authenticate the service account with Kestra from external applications such as CI/CD pipelines (e.g., in Terraform provider configuration or GitHub Actions secrets). :::alert{type="info"} **Note:** You can configure the token to expire after a certain period of time or to never expire. Also, there is a toggle called `Extended` that will automatically prolong the token's expiration date by the specified number of days (`Max Age`) if the token is actively used. That toggle is disabled by default. ::: Once you confirm the API token creation via the **Generate** button, the token will be generated and displayed in the UI. Make sure to copy the token and store it in a secure location as it will not be displayed again. ![service_account_create_2](./service_account_create_2.png) ## Users vs. Service Accounts vs. API Tokens You can create an **API token** for a regular user as well. While Service Accounts are recommended for programmatic API access to Kestra from CI/CD or other external applications, it's often useful to create an API token for a regular user, so that programmatic actions performed by that user can be tracked and audited. ![service_account_create_3](./service_account_create_3.png) Therefore, the difference between a service account and a user is that a service account is designed for programmatic access and doesn't have a password or personal information attached to it. Instead, it is authenticated exclusively using an API token. A user, on the other hand, can interact with both the Kestra UI and the API, and can be authenticated using a password or an API token. ## The purpose of service accounts Service Accounts are intended for programmatic access to Kestra from any other application, such as CI/CD pipelines or your own custom APIs. For example, you can use the token **to authenticate with Kestra Terraform provider or Kestra's GitHub Actions CI/CD pipeline**. ## Allocating service accounts to groups Each Service Account can be attached to one or more Groups such as a group called “Bots” that centrally governs programmatic access for CI/CD across multiple projects with just one Role. This is useful to manage programmatic access used by Terraform, GitHub Actions, or other external applications, in one place by attaching a single Role to that Group. Speaking of CI/CD, note that Kestra currently supports authenticating with either a basic authentication user or an API token: 1. Use the `--api-token=mytoken` CLI property to allow authenticating with a service account token: ```bash ./kestra namespace files update prod scripts . \ --server=https://demo.kestra.io --api-token yourtoken ``` 2. Use the `--user user_email:password` flag to the CLI to allow authenticating with a Basic Authentication access: ```bash ./kestra namespace files update prod scripts . \ --server=https://demo.kestra.io --user=rick.astely@kestra.io:password42 ``` ## Service account name convention When creating a new Service Account, make sure to follow the DNS naming convention. Specifically, the `name` property needs to: - contain at most 63 characters - contain only lowercase alphanumeric characters or hyphens (i.e., the `-` character) - start with an alphanumeric character - end with an alphanumeric character. Some examples to make that clear: - ✅ `my-service-account` is a valid name - ✅ `my-service-account-1` is a valid name - ❌ `MY_SERVICE_ACCOUNT` is not a valid name because it contains uppercase characters and underscores - ❌ `myServiceAccount` is not a valid name because it contains uppercase characters and camel case - ❌ `my-service-account-` is not a valid name because it ends with a hyphen. **Why do we follow such a restrictive convention?** We follow the standard DNS-style pattern to be ready for potential future use cases where we could, for example, forward the service account name to a Kubernetes pod's labels. This way, we ensure that the service account name can be used in a variety of contexts without any issues.