1. Overview
   1. A special Google account belonging to an application
   2. A member, WHO, and a resource, WHAT
   3. Service accounts are granted permissions to a resource
   4. Authentication is between application and services
   5. Identified by its email address
   6. Users are granted the serviceAccountUser role
   7. Google Managed
      1. Represents different Google services
      2. Automatically granted IAM roles
      3. e.g. PROJECT_NUMBER-compute@cloudservices.gserviceaccount.com
   8. User Managed
      1. Created for/by the user
      2. Based on enabled APIs in project
      3. e.g. PROJECT_NUMBER-compute@developer.gserviceaccount.com
2. Key
   1. Service account access is maintained by account keys
   2. Default service account keys are managed by Google
   3. Custom service accounts can use user managed (custom) keys
   4. User is responsible for managing public/private key pair
   5. Google maintains a public copy for verification
   6. Private key cannot be retrieved by Google
   7. Google-managed keys can be used
3. Scopes
   1. Legacy method of granting permissions for default service accounts on an individual instance
   2. Grant per instance permissions to other GCP resources via the instance
   3. IAM roles or scopes determines service account permissions for the instance
4. Best Practices
   1. Rotate user-managed service account keys
   2. Do not delete service accounts in use by running services
   3. Create a separate service account for each service
   4. Name service accounts to reflect use and permissions
   5. Do not check-in service account keys into source code or leave in download directory
   6. When using ServiceAccounts treat each app component as a separate trust boundary
   7. Restrict who can create, manage and access service accounts