Computing services such as virtual machine instances, container orchestration systems, serverless, etc., gain a lot of attention in the tech world, but storage and networking are also essential for almost all applications. Data storage is a broad topic covering a wide variety of storage mechanisms for different use cases. Networking is vital for service communication, and security is always important, though typically an afterthought.
As the technologies used to build distributed systems keep improving, data storage offerings continue to grow, evolve, and inspire new services. Having a better understanding of these different services can help us build better applications.
This course will help prepare you for the Google Professional Cloud Developer Certification exam, which requires a working knowledge of building cloud-native systems on GCP, and covers a wide variety of topics, from designing distributed systems to knowing how to create different storage resources.
This course focuses on the third section of the exam overview, concentrating specifically on the last four points, which cover data storage creation, networking, and security services.
- Create data storage resources
- Deploy and implement networking resources
- Automate resource provisioning with Deployment Manager
- Manage service accounts
- IT professionals who want to become cloud-native developers
- IT professionals preparing for Google’s Professional Cloud Developer exam
- Software development experience
- Proficient with at least one programming language
- SQL and NoSQL experience
- Networking experience (subnets, CIDR notation, and firewalls)
- Familiarity with infrastructure-as-code concepts
Hello and welcome. In this lesson, we'll be looking at service accounts. Specifically, we're going to cover the topics listed in the exam guide, which are creating a service account with the minimum number of scopes, and downloading and using a service account private key file.
Service accounts are designed to allow non-humans to interact with GCP APIs. Regular accounts are intended for humans: they have a username, they have a password and a set of permissions that define which actions that user is allowed to perform. Service accounts are similar, though they have a few differences. Each service account has an email address that represents the identity, though rather than passwords, RSA keys are used, and there are two types of keys. We have Google-managed and user-managed. Google-managed keys are short-lived, automatically-rotated keys, which are used by Google Cloud Platform when a service interacts with the Google Cloud API as that service account. As an example, Compute Engine instances can be run as a service account, allowing applications such as gcloud to assume the identity of the service account. So, Google-managed keys are used by GCP services to interact with other GCP services.
User-managed keys are used by code running outside of GCP. Upon creating a key, Google stores the public key on our behalf, and it allows us to download the private key. Because the private key is not stored anywhere inside GCP, if lost, will require a new key to be generated. After we have a key generated, it can be deployed alongside whatever code requires it. Ideally, it would be deployed following the standards used by the application default credentials, which checks for an environment variable called GOOGLE_APPLICATION_CREDENTIALS, and that should point to the service account key file.
Since a service account is a type of account, we have to manage its permissions, which is done via IAM roles. These days, IAM roles offer a rather granular set of permissions. In the old days, however, there were only a few roles, which were really too permissive or not permissive enough. So, if we start up a Compute Engine instance to run under a service account, and it takes on the permissions of that account, using the old-style roles, we would have either too much permission or not enough. So, to ensure that instances run with the least amount of permissions possible, Google created access scopes.
Access scopes used to be the primary way of limiting permissions. They're now deprecated as a means of limiting instance permissions in favor of roles. However, they do still remain in effect and are required when launching an instance as a service account. Since roles are the current best practice for managing permissions, the current recommendation by Google is to use the cloud-platform scope, giving that scope ultimate permissions, and then limiting those permissions using IAM roles. And since there's really not much else to talk about with service accounts, that is gonna wrap up this lesson.
Thank you so much for watching, and I will see you in another lesson.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.