What Type Of Authentication Is Best For VMs? A Conversation

We published another episode of “VM End to End,” which is a series of curated conversations between a “VM skeptic” and a “VM enthusiast”. Every episode, join Brian, Carter, and a special guest as they explore why VMs are some of Google’s most trusted and reliable offerings, and how VMs benefit companies operating at scale in the cloud. Here is a transcript of the episode

Carter Morgan: Welcome to another episode VM End-to-End, a show where we have a VM skeptic and a VM enthusiast come together to hash out all things VM-related. Thanks for being here today, Brian.

Brian Dorsey: Happy to be here. What’s the topic for today?

Carter: Oh, you know what it is. I need to know about identity, and I need to know about access. I want to know why I can’t just SSH into everything, or if I can. What can you tell me, Brian?

Brian: Okay. I’ll give a quick answer here, and then I will bring a guest in because I don’t know all the details. One, you can just SSH in. It’s a computer; SSH works with keys, so you’ve got a key pair, and it kind of works as when you have that token, you can get into any machine that the public key’s on. You can just manage those all yourself if you’ve got a system to do that, but it can get to be a lot and get quite complicated, especially as your organization gets larger. We have a way to delegate the creation of those keys to Google’s Identity infrastructure. That is why I wanted to bring in Emanuel, one of our colleagues who focuses on identity and access management. Welcome, Emanuel.

Emanuel Burgess: Brian, thank you for that amazing introduction. How are you today, Carter?

Carter: Yeah, I’m doing well, a little confused, but I think Brian can tell you where my struggles lie.

Brian: Emanuel, what’s the high-level [information] on identity and access management in Google Cloud?

Emanuel: Brian, that’s a great question. Let’s go back to defining what IAM is, right? IAM stands for identity and access management, which means that you can delegate or control who has access to what resources in your Google Cloud account.

Carter: Okay, so you can control who has resources or access to resources. Who’s setting that up?

Emanuel: Well, first, you need to set up a domain. There’s a person that’s called a super admin. The super admin goes into the admin console and sets up your domain. Once they set up your domain, it automatically creates an organization for you. Now, this super admin is a role that can do anything within the admin portal to manage users, create groups, set up multi-factor authentication, and more, all from the admin portal.

Brian: So we’ve got this super admin and domain, and the thing I’m used to looking at the most is projects. How do those connect?

Emanuel: Right. A domain one-to-one maps with an organization, and so if we think of projects, projects sit under an organization. You can think of an organization as a root node within your GCP account. With the root node, you can have things under them like projects and folders, and then you can assign resources to projects.

Carter: Oh. And, I take it, this hierarchal structure is what you use to access different areas?

Emanuel: Absolutely, there you go.

Carter: Then what about if I want a script or something to access Google Cloud’s resources for me? What do I do then?

Emanuel: If you want an external application or workload to access things within Google Cloud, you can use what’s called a service account.

Carter: What’s that?

Emanuel: You can think of a service account as a special account that can interact with APIs within Google Cloud. If we want to put this in context, let’s look at a user account. If I’m a user and have access to Google Cloud, I would go via Chrome to the Google Cloud browser or website, and then I would log in. When I put in my username and password, I’m authenticated. After I’m authenticated, I inherit the permissions or roles attached to a group I’m assigned to. But if I’m an application, I can’t do that, and I can’t go and log into Google Chrome, so I would need a service account to interact with APIs and services within Google Cloud.

Brian: Got it. That makes sense. So we have these organizations that give access to things. If I’m a user, I can get in one way; maybe I can SSH in. If I’m a program, I can connect to other APIs via service accounts. Are there any other ways programs get access?

Emanuel: Yeah. You have service accounts, and then you also have service account keys. Back in the day, in the way, way distant past, we gave external applications access to workloads or resources in Google Cloud using service account keys, but service account keys are problematic. One thing that makes service account keys a poor choice if you’re trying to securely build resources in Google Cloud is that they live on forever. So leaked service account keys can cause a major issue. In theory, whoever has access to your service account keys can impersonate a service account and get access to all the APIs and all the features attached to that service account. Then, in addition to that, this causes a secrets management issue. How do we manage these keys that are just floating around? You have to develop a secrets management strategy to safeguard and provide some peace of mind around these service account keys.

Carter: I never actually thought about some of these downsides of service account keys. I like the saying, these things from the way distant past. I love that. What you just talked about, though, made me think of something. It seems like service accounts are used for resources within Google Cloud. What if I have some service outside of Google Cloud that I want to authenticate into? Is there any way to let Google manage yet?

Emanuel: Well, yeah. We can do that. Let’s say I’m using Terraform to build infrastructure within Google Cloud. For me to do that long ago, I had to give it service account keys. I would set up Terraform, create a provider block, pass it my service account keys, and the service account keys would impersonate a service account within Google Cloud. That worked, but now I have to manage that specific key. Now we can use short-lived credentials, which means we don’t have to worry about managing service account keys. So now, if I want to build infrastructure in Google Cloud using Terraform, I can use short-lived credentials to authenticate Terraform with Google Cloud.

Carter: I love how excited you were to tell me more about these short-lived tokens–

Emanuel: I love it, I love it.

Carter: –because they are helpful. So thank you. All right, but now to the question before. Is it possible to get this kind of security or access to external workloads?

Emanuel: Well, yeah. We also have a feature that’s called workload identity federation. If you have external or outside of Google Cloud workloads that have their own identity provider, you can authenticate using short-lived tokens. What happens is you have an application that gets credentials from its identity provider, and then those credentials are passed to Google’s token service? Google’s token service takes those credentials and creates a short-lived external token it passes to the external application. Now, the external application can access and impersonate a service account within Google Cloud.

Brian: Got it. Okay, so we’ve got a lot of different kinds of access here. We’ve got users, service accounts, short-lived tokens, workload stuff. How do I decide which ones to use in a given situation?

Emanuel: I mean, that’s a great question. It all depends. Let’s say once again I’m using Terraform. Suppose I’m a user and have an external application that doesn’t have an identity provider. In that case, I can use short-lived credentials to authenticate that external application and impersonate a service account within Google Cloud. If I have a workload that has an identity provider, let’s say I’m using AWS for my identity provider, or I’m using on-premise Active Directory or Azure Active Directory, or let’s even say I’m using Okta. In those cases, it would be best to use workload identity federation so you can dynamically generate keys and not have to worry about manually generating keys from the gcloud command-line or one of the other methods.

Brian: And then all of this taps into IAM. That’s awesome. So you’ve got a consistent way to look at it, and that’s super cool. If somebody wants to dig in more on this, where should they start?

Emanuel: To get more information about IAM, security best practices, workload identity federation, short-lived credentials, you would go to cloud.google.com/iam/docs.

Carter: Yeah. Thank you so much for coming in, Emanuel! I had never heard of short-lived tokens, I never heard of workload identity federation, and I never really thought about some of the downsides to even service accounts and the long-lived static keys. To recap, would you say using IAM is a best practice?

Emanuel: Absolutely. I think if you’re working in any large organization, setting up IAM using organizations is the best way to go. Now, if you wanted to just play around with Google Cloud, you could sign up with just your Gmail account, but if you did that, that wouldn’t give you access to all the benefits of organizations. If you’re at a large enterprise, organizations to invoke IAM on your Google Cloud account is the best way to go.

Carter: Wow. That’s about all. I learned so much today about workload federation, short-lived tokens, and more. Brian, thanks for bringing Emanuel on. I got to give you props.

Brian: No, thank you, Emanuel. This was great.

Emanuel: I appreciate you, Brian and Carter. Thank you guys for the opportunity.

Carter: Yes. I learned about short-lived tokens and workload federation. If you’re listening at home, leave a comment about something you learned. Thank you, and that’s all for this episode of VM End-to-End.

Special thanks to Emanuel Burgess, Developer Relations Engineer at Google, for being this episode’s guest!