0

I've recently started some work on Google Cloud Platform (GCP) and while developing the auth strategy for my company, I've repeatedly come across the recommendation to use service accounts for authentication. That makes great sense for many situations. An app or service shouldn't have a user account. And in that link, Google actually lays out the original intent behind service accounts:

A service account is a special type of Google account that belongs to your application or a virtual machine (VM), instead of to an individual end user.

But the service-account pattern dominates all tooling around GCP. Unlike a ~/.aws/credentials file, there's no good way of using user credentials from CLI without making your user account appear as a service account with convoluted workflows like gcloud auth application-default login, so recommendations frequently extend beyond usage by apps and services to scenarios where a human will be behind the wheel.

Tools like Ansible and Terraform are some examples of third party tools that make these recommendations. I understand that often you'll be running these tools in an automated pipeline, but there are certainly cases where individuals will run them. The pervasive recommendation to always use service accounts for everything has led to a pattern where Developer Jim locally creates credentials for ServiceAccountA and then uses those!

Here's my problem with this: you lose auditing! Non-repudiation is a core part of information security, right? Why is the primary authentication method for GCP to use service accounts when all the audit logs lose non-repudiation value? In order to tell that Developer Jim was the one that did a bad thing instead of Developer Sally, you'd need the audit log in StackDriver to look like this:

authenticationInfo: {
   principalEmail:  "jim@mycompany.com"    
}

But since Developer Jim always follows best practices (or really the only pattern supported by many tools), he uses a service account to deploy changes and the audit log looks like this:

authenticationInfo: {
   principalEmail:  "deploy-service@myproject.iam.gserviceaccount.com"    
}

With this entry, how can you tell who did what?

Am I just misinterpreting the recommended practice or does the recommended practice really eliminate non-repudiation?

0

There are two primary authentication methods in Google Cloud: User Credentials and Service Account Credentials. I am ignoring API keys, etc.

The reason that Google recommends using service accounts (where applicable) instead of user accounts is the processing for user accounts is much more intense for Google. The process takes longer, there are more security checks, etc. There is an API limit on how many times you can authenticate with user credentials in a certain period of time. The exact numbers are not published.

Service Accounts contain all the components necessary to authenticate with Google Cloud and require fewer interactions to generate OAuth tokens.

Service Account JSON key files are assumed to start in a secure environment. User Credentials are assumed to start in an insecure environment.

Service account credentials are typically used for service-to-service, installed software, etc authentication/authorization that may happen over and over again.

If you are using the same service account for each user, then yes, you lose a piece of the audit trail. However, you should not be distributing one service account JSON key with the application. You should issue a different service account to each user. Your example then becomes john-smith@myproject.iam.gserviceaccount.com. The user should protect the service account credentials in the same manner that he would protect his email credentials.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.