[RFD - 0003] - Service Accounts

[AleksandarCole]

[RFD - 0003] - Service Accounts

Authors	State
@darkofabijan @radwo @lucaspin @DamjanBecirovic	In queue

What

Semaphore Service Accounts are special accounts made for automated processes and bots. They let organizations create new Semaphore accounts and give them specific permissions for certain tasks, making it easier and safer to manage access to resources compared to giving permissions directly to individual users or groups. Service Accounts do not have access to the UI, ensuring they are used solely for automation purposes.

With service accounts, managing permissions becomes simpler. Each service account can be set up with only the permissions needed, ensuring automated processes have just the right access. This reduces the risk of unauthorized actions and improves overall security.

Why

Implementing Semaphore Service Accounts enhances security and manageability within the organization. By assigning permissions to service accounts instead of directly to users or groups, we can achieve the following:

• Increased Security: Service accounts limit access to specific resources, reducing the risk of unauthorized access or actions by individual users.
• Better Access Control: Permissions can be tailored precisely to the needs of automated processes, ensuring that service accounts have only the necessary permissions.
• Improved Manageability: Service accounts simplify the management of permissions, especially in large organizations with complex access requirements. They provide a clear and centralized way to control what automated systems and bots can access.
• Compliance: For organizations adhering to security standards and regulations, service accounts offer a method to enforce the principle of least privilege, helping to meet compliance requirements.

By leveraging service accounts, organizations can streamline their access control mechanisms while maintaining robust security and compliance practices.

---

Use-cases

Case 1 - Pipeline triggers across multiple projects

In this scenario, an organization uses Semaphore Service Accounts to automate pipeline triggers across multiple projects. They achieve this by making an API call in Project 1 to start pipelines in Project 2 and Project 3 automatically. Instead of using user API tokens, they prefer to use Service Account 2 and Service Account 3. These service accounts are set up with specific permissions to start pipelines in each respective project.

By using service accounts, the organization ensures that their automation process is secure and well-managed. It allows them to automate workflows smoothly without needing to expose personal user credentials, keeping everything safe and running efficiently across their projects.

Case 2 - Read only access on all projects in organization

In this scenario, an organization manages multiple Semaphore projects where no single user has access to all of them. To periodically gather information on completed pipelines for their internal dashboard tool, they use a service account approach.

They create a dedicated service account with read-only permissions for workflows and assign it to all projects. This service account allows them to run API calls without needing to grant any user full access to all projects or rely on individual user tokens. This setup ensures they can centrally monitor pipeline activities across their projects securely and efficiently for their internal reporting needs.

---

Feature Description

Access Control

Access to the Service Accounts feature

• Users with the appropriate organization role permissions can create, view, edit, and delete service accounts within the organization.
• A new set of permissions will be created for the service account feature and can be assigned to organization roles through the Custom Roles feature.
• By default, these permissions will be enabled for the Owner role in Semaphore.

Assigning access to the Service Account

Service Accounts do not have access to the ui. They can interact with Semaphore only through API calls or cli commands.

Project access is controlled by adding the account to the project and assigning appropriate project roles to the Service Account.

For example, if a service account should be able to trigger workflows on project 1 but only view (get description of) workflows on project 2, then the account should be added to project 1 with the Contributor role and to project 2 with the Reader role.

⚠ Important: Unlike User Accounts, Service accounts cannot be connected to GitHub or BitBucket.

Managing Service Account

When creating a new Service Account user provides:

• Account name
• Account description
• Organization role (initial set of permissions)

Once the Account is created, user receives a generated API token for the account.

This token works similar to current personal API tokens - it can be refreshed as needed.

Auth. token functionality can be extended further in future iterations:

• Introducing the ability to have multiple tokens per account
• Setting the expiration time for each token
• Introducing the ability to auto-rotate tokens

UI Changes

UI changes are still to be defined. Service Accounts can either live:

1. In the dedicated page within Organization Settings
2. Within the existing People page.

Service Accounts in People Page

1. People page is renamed to People & Accounts
2. Service Accounts are added as a separate category within the page
3. Users with adequate access can create new Service Accounts
4. Organization role can be changed, or account deleted from organization
5. Manage Accounts opens a single page where name/description can be edited and token reset
6. Metadata like role assigned, number of projects account has access to etc. can be integrated in this view

Pros:

• Groups, Users, and Service Accounts are all on the same page, improving visibility into access control within the organization.
• The People page can be updated to display more metadata for each category.
• Users can easily search through all accounts within the organization (user or service).
• The UX pattern is consistent with the project people page.

Cons:

• It may clutter the People page.
• Separating view rights for Service Accounts, People, and Groups could be challenging on a single page.
• Some organizations may have a large number of service accounts, making it unwieldy to have them on the same page as user accounts.

Current State and How to contribute

⚠ This feature is still in the R&D phase
This means that the functionality scope, UI patterns, and implementation details are still to be decided.

If you are interested in this feature help us shape it further by:

• Sharing your use-case in the comments
• Share any ideas for improvement
• Raise any concerns you may have
• Share your experiences in using similar features in the past

[cchristous]

Service Accounts do not have access to the cli or ui. They can interact with Semaphore only through API calls.

It's interesting that you exclude the cli access from service accounts. Why is this the case? I think we could do the same things through API calls, so cli access isn't a requirement. However, the cli is generally easier to use than the API, so it is a nicer way to interact with the server.

Auth. token functionality can be extended further in future iterations:

• Introducing the ability to have multiple tokens per account
• Setting the expiration time for each token
• Introducing the ability to auto-rotate tokens

Definitely would like to see auto-rotation in the future. With static credentials, the user has to do the rotation implementation.

[AleksandarCole]

@cchristous thank you for the feedback 🙌

Service Accounts do not have access to the cli or ui. They can interact with Semaphore only through API calls.

This one is an error on my end. Only the access to the UI will be disabled for the service accounts, cli on the other hand will still be available. I updated RFD to reflect this.

---

Definitely would like to see auto-rotation in the future. With static credentials, the user has to do the rotation implementation.

Yeah, team also feels like this will be a big QoL improvement. The first version may ship without this functionality, but I do think the auto-rotation will quickly follow the initial rollout.