How to get the most out of Google Cloud Platform’s Security At The User Access Level.

Policy as code is a concept that can be tough to get your hands around sometimes. In this episode of CloudUp, we’ll be talking about Google cloud permissions, managing that via infrastructure as code and describing how that process works.

Meet the Speakers

Han Kim

Han Kim

Principal Architect

Jeremy Pries

Jeremy Pries

Director of Cloud Infrastructure

Transcript

– The next logical step, generally, is to look at how DevOps can manage that process. And we can do it iteratively, where we look at a methodology to use code to do the same things that you would do as you click around in the console. And that process by which you check in code to a repository, and what you checked in, then goes through a pipeline, enabling it to be checked against policy, and then implemented. That now gives us the things that we’re missing, which is the who, what, when, where, and even sometimes why, and the auditability and traceability of the permissions being set and who set them.

– Today we’ll be talking about Google cloud permissions, managing that via infrastructure as code. So Han, policy as code is really a concept that’s tough to get your hands around sometimes. So it could even be at the top of an organization, the GCP organization itself, and how you manage things, permissions as they trickle down. Can you describe a little bit about how that process works?

– Well, traditionally, I think, all people just kind of experiment in the cloud first, as they get familiar with the idea of using cloud. And they go into the consoles and start clicking around and look at permissioning users individually, or permissioning things around in Google’s cloud at least, folders and projects by clicking in the console to easily stand up those kinds of resources. And I think this is where people get trapped because they think of this as easy and they continue that process without thinking about the additional aspects that affect governance like the separation of duty, the audibility, compliance and sec ops.

– Yes, so it gets to be hard when you don’t know where you’re gonna go, from day one at GCP, you wanna maybe stand up a VM or something and kind of see the environment. And eventually you have a large chunk of your business that runs there. How do you go about, so I started pointing and clicking throughout the UI, and I saw, there’s a big bunch of chaos there at the top level of IM, so then, what’s my next step, then? I need to try to tighten that up and control it more, right?

– For sure, I think that the next logical step generally, is to look at how DevOps can manage that process. And we can do it iteratively, where we look at a methodology to use code to do the same things that you would do as you click around in the console, and that process by which you check in code to a repository, and what you checked in, then goes through a pipeline, enabling it to be checked against policy, and then implemented. That now gives us the things that we are missing, which is the who, what, when, where, and even sometimes why. And the auditability and traceability of the permissions being set and who set them.

– Oh, cool, so like, just like when I release my code through a pipeline, I cut out various steps that happen, besides just hooking up GCP to a get repo and having it provisioned directly from there, you’re saying, right? We could have different approval steps or whatever.

– Yeah, and I think just like you’re saying, if we look at development and code, the same thing applies directly to infrastructure. Infrastructure as code kind of implies like it’s equivalent to any other type of code. All CS code, application code. And in the other areas, aside from infrastructure, there is a linting, checking, things that test the code prior to it being implemented, so that we know ahead of time before it’s out in the wild that I give too many permissions or too broad of permissions. And that’s what helps us to begin controlling the wild west of just throwing users out one by one.

– Yeah, cool, then I’d have like versioning too, right? So I am at the top of the org, but there’ll be plenty of times where my infrastructure chain broke something, and I wanna back it up.

– Right, and I think that that’s the key, because if you do it by someone clicking around, you can’t go back to who did it, exactly and what exactly was done. There’s no history of that and so you lose the ability then to fix or quickly identify what the problem is so that you can fix it.

– Quick is the key word there, right? I mean, you can go back through your audit logs and see Han made this change. But it’s very tough to see what the rest of the state of everything was at that time. Unlike, a commit through a get repo. Right, and I think that that is the key because if you have collaboration going on, and there’s more than one person running this thing, there has to be a mechanism that we can see the contributions, changes and requests that come in. And as you said, checking that into a repo gives us that information. Thanks for watching. Let us know what security issues are important to you.