Introducing BastionZero Service Accounts for CI/CD Tools

Service accounts are an integral part of many modern workflows, especially those related to continuous integration, continuous delivery, and continuous deployment (CI/CD) tools. But managing their interconnectedness presents a unique challenge to IT and security teams. Elevated privileges enable these teams to execute applications with ease—but it is precisely this high level access that can create security risks if not managed correctly. In this blog post, we'll explore the benefits and risks associated with service accounts and how they impact your organization’s security posture.

‍

This is the third installment of our series of blog posts on the security of CI/CD pipelines. In this post, I’m covering the basics of BastionZero Service Accounts. The fourth blog post in this series will discuss an additional “MFA for Service Accounts” feature we’ve developed to ensure our Service Accounts are robust to compromises of the CI/CD pipeline itself! Watch out for that post, authored by our Head of SE/CE Devin Bernosky, which will be out in the next few days!

‍

What Are Service Accounts? 

Service accounts are a unique kind of account that isn't associated with any one person, but instead is used to execute applications and run automated services, virtual machine instances, and other processes. Organizations often leverage privileged service accounts to further streamline the software development lifecycle with CI/CD.

‍

Service accounts can range from privileged, local to domain accounts, with the potential to possess domain administrative privileges. This immense level of privilege facilitates the smooth operation of many IT workflows because a single service account can be leveraged across many applications or processes.

‍

Common Risks of Service Accounts

While service accounts offer a number of benefits, they also come with some risks. One of the biggest risks is that service accounts often have long-standing credentials that are difficult to track and monitor. If a threat actor gains access to a service account, they could potentially gain unrestricted access to your organization’s entire infrastructure without being detected. 

‍

It’s also not uncommon for credentials to be shared among multiple users, making it hard for administrators to determine who has access and is responsible for what activity. This lack of visibility can effectively extend indefinitely if organizations do not—or are unable to—revoke these kinds of unchecked access privileges when employees or contractors leave the company.

‍

BastionZero (BZ) Service Accounts vs. Service Accounts

Unlike traditional service accounts, BZ Service Accounts provide organizations a breakthrough automation capability without compromising on security or convenience. With this release, organizations can use BZ Service Accounts to access any type of target that can be accessed by a human user of BastionZero, including servers, containers, clusters, database, webservers, etc. 

BZ Service Accounts offer not only the core functionality expected from service accounts but also the same benefits that human users of BastionZero receive: command logs; session recordings; credential rotation; and robust policy enforcement, including instant revocation. Plus, BastionZero’s trustless access architecture—which utilizes two roots of trust (ROT)—ensures that the BastionZero cloud service never becomes a point of compromise for your infrastructure or has privileged access to any of your infrastructure targets.

‍

When using BZ Service Accounts for CI/CD tools, organizations can use the same account management features they would use for named SSO users across all targets within their infrastructure. BastionZero supports three types of service accounts: Generic, Google Cloud Platform (GCP), and Azure service accounts (SA). All of our service accounts are based on  JSON Web Key Set URLs (JWKS URLs). With GCP and Azure SA, the cloud platform handles some of the setup (and the hosting of the JWKS URLs). Meanwhile, generic service accounts provide organizations with the flexibility of hosting their own JWKS URL if desired. 

The Benefits of Using BZ Service Accounts for CI/CD Tools 

BZ Service Accounts offer numerous advantages over traditional service accounts, including:

• Robust Policy Enforcement: Organizations can control access to infrastructure targets through centralized policy, enabling teams to implement least-privilege and control which user or machine can assume which role on which target, across all clouds and environments. Service accounts can easily be revoked using BastionZero’s centralized policy manager, which makes it easier to onboard and offboard accounts as circumstances change or people leave the organization.
• Improved Visibility through Command Logging and Session Recording: Organizations can memorialize each time your Service Account accesses your infrastructure through our auditing capabilities. 
• Automatic Credential Rotation: Utilize our command line interface (CLI), the Zero Trust Command Line Interface (ZLI), to simplify rotation of a Service Account’s BastionZero credentials using zli service-account rotate-mfa <serviceAccountEmail>.
• Instant Revocation: If there is a compromise of your service account, reduce the potential impact of a breach by instantly revoking your Service Account’s access privileges. Pair this with closing all active connections to minimize the risk that a threat actor can damage your organization.

‍

How to Set Up a BZ Service Account      

Let’s walk through how I set up a BZ Service Account for GCP and onboarded it to my BastionZero organization in less than 10 minutes:

‍

• Create a service account in the Google Cloud Console in a new or existing project.
  
  In my case, I used an existing project, ann-service-account-test. From the main console, navigate to the “IAM & Admin” section, then “Service Accounts,” and finally choose “Create Service Account.” I named my service account ann-service-account, which resulted in a service account email of ann-service-account@ann-service-account-test-iam-gservice.com. Be mindful of your service account ID and project name if you would like a shorter service account email.
• Generate a JSON key by selecting the service account and navigate to the “Keys” tab.      
  
  This is the public/private key pair that acts as the first root-of-trust for authenticating to BastionZero. Google requires you to save this file locally on your machine, and as a security best practice, we strongly recommend saving this information securely, such as in a vault.
• Transitioning from the Google Cloud Console to BastionZero, log in to the Zero Trust Command Line Interface (ZLI), our command line interface. 
• Add the newly created service account to your BastionZero organization via zli service-account create <provider-file.json>.
  
  The provider-file.json is the credential file saved from step (2). The filename follows the structure {Google-project-name}-{first 12 digits of the key id}.json. This command generates a bzeroCreds.json file that is saved to the current working directory. This file contains the second root-of-trust required to authenticate to BastionZero: the independent MFA token. This information should also be stored securely.
• Update your policies and targets to allow access as the final step.
  
  I personally prefer to modify policy through the BastionZero web app; however, it can also be done from the ZLI directly by using zli policy add-subject <policyName> <email>.
  
  To enable my service account on all existing targets, I used zli service-account configure --serviceAccount ann-service-account@ann-service-account-test-iam-gservice.com --all.
  
  This command configures all bzero agents v. 7.3.0+ with the service account’s public key so they can verify ann-service-account@ann-service-account-test-iam-gservice.com’s identity. If I had wanted to specify a subset of my existing targets, rather than use the --all flag, I would have used --target, followed by my list of targets, delimited with spaces.
  
  
  

USEFUL TIP

To test my configuration, I logged in to the ZLI as ann-service-account@ann-service-account-test-iam-gservice.com using zli service-account login --providerCreds /path/to/provider-file.json --bzeroCreds /path/to/bzeroCreds.json, and verified my policy updates by executing a zli connect command.

‍

To summarize, BZ Service Accounts offer a more manageable solution for teams who want to replace their traditional service accounts with an alternative that offers easy credential rotation, multi-root authentication, and centralized oversight and management of actions taken and privileges granted.  

To learn more about how to set up a BZ Service Account, take a look at our setup guide. To try it out yourself, you can do so through our free tier. For questions or to offer feedback, reach out to us at product@bastionzero.com.