Lately I have been working extensively on “Policy” with large organizations that develop software. Since the “cloud” and “cloud native” movement started we see orgnizations starting to be divided to consumers and providers, where the providers are those that develop software and provide services to their own customers, and consumers are those that moved to only consume cloud services and no longer in the business of IT.
These “provider orgs” are facing new challenges that are stemming from the need to operate in a distributed, multi-cloud multi-platform environment, for which has many implications but the one that relates to this blog is policy management and enforcement. Interestingly most of my conversations about policy are with the security folks, and the question arises, is policy synonymous with security? Why when we talk about policy we do it mostly in the context of security and compliance, which on their own are two different things? And why the topic of policy so related to “cloud native”? One needs to understand these things to be able to address the more complex architectures of how to address the challenges.
When we talk about security we usually refer to the following things:
- Hardening – set of “best practices” to close hols in our security posture. can be applied to anything from operating system to your network
- Governance – the validation that someone or something is allowed to do something
- Access – open access or close access from one entity to another. Mostly refers to network access but can be other things like API access etc.
These “security” dimensions have relationships with each other and can overlap, for example by hardening the network I revoke access for certain entities or allow access only to others. But at the end of the day we will apply these security dimension using different methodologies and tools such as (buzzword warning) “Zero trust”, “RBAC”, API controls etc
The best definition for what is policy I could find , is on Wiki of course, and from that this: “A policy is a statement of intent” which is perfect definition to explain how it is tied to “Cloud Native”, more on that later. So a security policy would be a definition of our security intent, and our intent would be our desired security posture. But, policy does not have to be just security, we know many other types of policies such as SLO policies, business policies etc, so why discussions about policies are carried mostly in the context of security? That’s because a policy defines things and actions that are allowed and not allowed, and naturally that fits the for security conversations.
A word about compliance, because compliance sometimes is conflated with security. Being compliant doesn’t mean being secure, its means that you are compliant with a set of requirements, e.g. HIPAA, PCI, SOCKS. Your security policy can include the requirements to get you compliant but they will probably include much more. Regulatory security requirements are usually treated as a minimum one must meet in a certain environment, for example HIPAA is how to treat ePHI data.
Back to Policy, a policy is a description of intent, as we said is a very “Cloud Native” definition, why is that? In the CNA way, desired state is declared rather than in traditional IT where systems are imperatively configured.
The best example for that is how Kuberenetes operates which is the platform of choice these days for running and developing software on, being declarative API we define our “desired state” and the Kubernetes with it’s custom resources figures out how to get us what we asked for (of course there’s a lot more to it but I am simplifying for our discussion).
So policy being a definition of our intent, is very helpful to apply security in cloud native, if we can describe it as code, and once described as code we can run it through our software supply chain in a “Git-SecOps” way.
For this purposes we have system such as OPA (open policy agent) which has a unique declarative language for policy, can integrate to anything that can generate a JSON, can work as a sidecar for faster responses and in Kubernetes specifically can be an admission hook, which means we can govern and validate every action being taken on the platform. OPA is very popular but not the only system that can do this. At the end of the day, what most organisations that develop and run software are after is making security work at the speed of the business without compromising, security. So being able to define our security desired state policy (or any other policy) as code, and as part of the software delivery chain removes bottlenecks on the path to faster better innovation.
I hope this post helps make sense the relationship between policy, security and how it fits in a “cloud native” world. There is a lot more to address in this space, but I’ll leave this to future posts.
For more about securing multi cloud applications see my post about “Securing a multi-cloud application”
As always, if you liked this post, let me know by leaving a comment or on the social mediaz, and share
Cheers
Niran
Leave a Reply