Policy As Code: How to get the most out of Google Cloud Platform’s Security

Policy as code can be a big benefit to security departments in controlling what their users and their self service users are doing, but what are some of the other things that are good about implementing policy as code? In this episode, we talk about policy as code and how it affects security in the cloud.

Meet the Speakers

Han Kim

Han Kim

Principal Architect

Jeremy Pries

Jeremy Pries

Director of Cloud Infrastructure


– Policy as code can really be a big benefit to security departments in controlling what their users are doing, their self service users are doing, but what are some of the other things that are good about implementing policy as code?

– Policy as code addresses the issue that, can you really expect IT to handle the provisioning of infrastructure, the security, the compliance. Like there’s no separation of duty, there’s no overarching security concern that cuts through all of the IT development requests, for instance. So I think it’s critical that we implement something at an organizational level that helps keep those things under control, aside from saying, “hey, random IT guy or random developer, “we expect you to manage all of the security compliance “and also integrate the duties “with what you’re doing right now.” I think that’s a bit of a huge request for people. Today we’re gonna be talking about policy as code and how it affects security in the cloud. So, you know, Google has always claimed that they have superior security, compared to the other public cloud providers. And I feel like that was true in the beginning, but none of that really kind of influences the buyer anymore because there’s a lot of feature parity now. Like the whole idea of encryption at rest and internal network security of TLS and all these things that are definitely security features are now available in one form or another, on all the public cloud providers. And even by using those aspects of the security, there are many ways to bypass them, which generally comes from, you know, how you architect your environment and how you set up your projects, et cetera. And I think that people don’t really understand that in bank security from the platform is not enough to guarantee that what you’re doing is secure.

– One of the problems with trying to choose a cloud based on the one with the, that’s the most secure, is the fact that roadmaps are aggressive. Everyone’s spending a ton of money on advancing their features and no one wants to be outdone by the other cloud. And so we’ve found it hasn’t really turned into a differentiator, that one cloud has security feature X versus Y. We don’t live in the annual cycles anymore and the roadmaps are aggressive and security features continue to be added. And, you know, feature based sales are not the right way to make a decision about which cloud to use.

– Yeah, I agree with that completely. I think that in the beginning, there was that trepidation of, like, on prem we have such control over our environment and our access and our machines. And now we’re kind of giving them control up by putting it someplace that’s outside of our reach directly and all software defined. But I think that what people don’t understand is that the process by which you manage, both on prem and also in the cloud. That process is what really gives you the security that people are looking for.

– Yeah, the days of the Department of Know or the IT department pushing buttons for people aren’t, we’re just not there anymore. People expect immediate results and want the ability to do things themselves, instead of opening a ticket and asking someone else to do them. So, we’ve found this turns into a little bit of chaos on the cloud implementation from a security perspective, where sort of random things end up. It looks random at least. And when you look at the end result of a period of time of people provisioning things themselves.

– For sure. And I think that that bad habit sort of carried over from the on prem idea of how to manage infrastructure and how to manage security. Typically speaking, when someone needed resource, a ticket was created and someone in IT would just click around and stand up the resource. Or, you know, look at ways of manually provisioning, as you said. And I think that that’s where the errors kinda creep into the architecture of your environments and your processes. Because without any kind of automation or DevOps overlay that controls that process, it’s really easy to just create situations that open giant security holes in your infrastructure.

– Yeah, so it maybe gives a little bit of oversight or control over the chaos, so we’re not surprised by the things we find during our routine security audits or, you know, finding them after the fact.

– Well, just even the ability to have audits is a great thing, right? Like we’re talking about security and issues where, you know, things happen where we create vulnerability in the organizations while we use public. Let’s try to minimize that. How do we minimize that? And the ways to minimize it are strategic, right? They’re not tactical where you can expect everyone to kind of chip in to understand the organizational security needs. You have to kind of put that into place and tell people, “no, this is not correct. “Yes, this is allowed.” And the only way to really do that unilaterally is policy and policy as code is usually the way that we go. Thanks for watching. Let us know what security issues are important to you.