Service Accounts (SA): Fortifying the Homeland

Service accounts(SAs) are a special type of Google account that grants permissions to GCP resources instead of end users. Service accounts are primarily used to ensure safe, managed connections to APIs and Google Cloud services. Granting access to trusted connections and rejecting malicious ones is a must-have security feature for any Google Cloud project.

In order to understand the threats to SAs companies must start with broad Org level IAM audits to gauge where these powerful IAM accounts stand in the present. Overly Permissive SAs at different levels of the GCP heirarchy are weaknesses that can cause havoc in GCP and should be reviewed regularly to maintain a consistent secure IAM posture.

At the Application level, specific SAs should not have access to both GCP Folder production and non-production environments. This process of cross pollinating SA accounts should never be recommended as a best practice for domain folders such as Production and Non-Production. This practice lowers the SA account security posture as a least privilege model within a Zero Trust Architecture. The result? In a worst case scenario an SA granted full access to non-production could theoretically use those permissions in a production environment to destroy everything and anything in its way. A total nightmare for enterprises!  An even bigger nightmare is if a basic role (Owner, Editor) tied to SA has been set at the GCP org level in the hierarchy. If this were to occur the potential of homeland destruction increases 10-fold.  This SA, if compromised by a bad actor, can now roam freely at will throughout the entire GCP environment.

So what happens when an application fails or any other emergency situation presents itself in a GCP environment?  Where is the Bat-phone located? Who can reach the hammer to crack the glass enclosure?  If the hammer is used, then what?  These are questions to be addressed within a standard Break Glass process.  IT companies have struggled to properly identify and implement a rapid reactionary method of protecting the homeland.  In the GCP world a Break Glass solution can utilize “Service Account Impersonation.” This is a sophisticated approach that allows users to assume an SA permission set while abandoning their own. Access is granted ahead of time to a small trusted set of subject matter experts (SMEs) who are approved by management and security. When an agreed upon Break Glass event occurs, internal processes and workflows are kicked into high gear and the user impersonating the SA does what he/she does best, puts out fires!


​

Angel Rosario

LucidPoint Cloud Engineer