Why is it recommended to use GCP service accounts vs user accounts?
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?
