What is Policy as Code?
From startups to large organizations, handbook-based policy management rarely scales well and is often applied in a non-uniform way. Policy as Code addresses this by codifying policies, providing visibility, and enforcing them automatically. By adopting Policy as Code, an organization forces itself to translate its policy decisions into code that enforces decisions in the same way, every time.
Under Policy as Code, policies are standardized into records readable by both the people who manage them and the systems that enforce them. Policies written in formats like YAML and JSON allow this, because they’re consistent enough for an authorization system to enforce and simple enough for security personnel to read.
With machine-readable policies, authorization can be offloaded to security software, reducing the toil necessary to constantly monitor and maintain one-off requests, freeing development teams to focus on core features.
With policies stored consistently and globally, realtime auditing of access grants is possible for the first time. Security teams can monitor and review authorization decisions and policy changes, allowing the entire company to move faster without breaking core security and compliance requirements.
Benefits of Policy as Code
Policy as Code reduces toil for IT and security teams by helping to automate workflows that are typically done manually.
- Simplify Onboarding/Offboarding
You simplify onboarding of new employees, removal of access for departed employees, and rollout of new tools and technology. - Gain Full Tracking/History
You no longer need to traverse different systems to track down the full policy documentation that may have been stored in your standard tracking system and in other communication systems. Full tracking and history is now visible instantly in the organization’s version control system, where the responsible teams can view every policy and permission change. - Improve Approval Process
You reduce the toil of approving and denying requests. By codifying your decisions, those who grant access no longer need to perform the legwork to determine if someone should get access or not. Permissions can be auto-provisioned at exactly the level each user or group needs, and no more. - Eliminate Guesswork for Role-Based Access
Policy as Code takes the guesswork out of granting permissions and applies your policies uniformly across every request, from any application, tool, or user. Once Policy as Code is integrated with your organization’s directory service and groups, it becomes possible for the security and IT team to implement true role-based access. - Reduce Uncertainty
Policy as Code gives managers and employees a clear view of access privileges throughout the organization, and reduces uncertainty. Permissions can be reviewed by the right people, anywhere in the organization. When a change is needed, the request can be submitted and reviewed in a standard, well-tracked way. - Allow for Self-Service Options
Optionally, employees can self-serve some permissions requests thanks to automatic policies that evaluate the user’s role, their group affiliations, and the sensitivity of the resource being requested. Whether changes are streamlined or self-serve, employees appreciate autonomy and transparency because it cuts the confusion about how or when their request will be reviewed. - Gain Real-time Audit Logs for Compliance
Finally, by clearly tracking all permissions changes, an organization has a real time audit log that reduces the work needed to prepare for compliance and certification reviews. With a clearly defined system of record for security policies, approvals are tracked automatically, and there’s no longer a need to search multiple systems to get a full picture of access rights.
As you can see, the benefits of Policy as Code can have a big impact on reducing manual work, and improving processes in a variety of ways. Let’s dig in more into how this is put into practice and we’ll take a look at a few examples of how to create policies and provision or deprovision access.
Examples of Policy as Code
Access Provisioning
Usually, when a new developer, say Frank Hardy (username fhardy), joins the organization, a JIRA ticket like the one below will show up in the inbox of an IT/DevOps admin:
Even at this beginning stage, many things can go wrong, starting with the ticket itself being filed against the wrong person or team, or as is often the case, not having enough information, leading to a tedious back-and-forth between requester and administrator.
On the other hand, using an Access Management as Code framework, the developer’s manager just submits a pull request in a version control system such as GitHub with details as shown in this example:
Requests now can follow the standard checks defined in your version control system, including limits on who can change what (“protected branches”) and required approvals. This ensures that each request—like our onboarding request—always goes to the admin in charge.
Along with GitHub access, let’s say fhardy’s job function requires access to the staging MySQL database as well. The following Terraform code accomplishes this by creating a user called fhardy and assigning it to a developer role.
resource "mysql_user" "fhardy" {
user = "fhardy"
host = "staging-mysql.platform.acme.com"
auth_plugin = "AWSAuthenticationPlugin"
}
resource "mysql_role" "developer" {
name = "developer"
}
resource "mysql_grant" "developer" {
user = "${mysql_user.fhardy.user}"
host = "${mysql_user.fhardy.host}"
database = "app"
roles = ["${mysql_role.developer.name}"]
}Creating Policies
Continuing with our example, the next step in the Access Management as Code journey is to make sure privileges for the user fhardy are set up correctly. This can be automated in a number of ways, depending on your environment. In the example below, we’ll show how it would be done using Styra’s Open Policy Agent (OPA), a policy framework that integrates well with popular cloud stacks. OPA helps to decouple policy from the service itself. OPA policies are written in Rego, a language that allows for declarative, fine-grained control.
For example, you could use OPA with a built in-house internal CMS tool to govern developer access to an organization’s customer data repository. The following OPA code shows how to only allow the members of the CMSAdmin group to see customer contracts.
package httpapi.authz
import input
# Allow CMS admin members access to customer contracts.
default allow = false
allow {
input.method == "GET"
some contractId
input.path = ["contracts", contractId]
input.user == cmsAdmins[_]
}
# Only the following belong to the CMS admins group
cmsAdmins = ["ndrew", "mwang", "fhardy"]Once the above validation is implemented using OPA, only members of the CMSAdmin group can see customer contracts in the CMS tool.
Example: Access Deprovisioning
Using Terraform, deprovisioning is as simple as deleting the relevant lines of code from the terraform script and generating a pull request. Once the pull request is peer reviewed and merged, running terraform apply would automatically revoke access.
Below is an example of revoking fhardy’s access to the organization’s GitHub account.
Summary
Using manual processes and reviews for policy enforcement can take a toil and leave your organization at risk. Policy as code can unify and automate your policies while providing you with greater visibility for auditing and compliance. This approach extends on infrastructure as code, which brought similar benefits. Cyral has built Policy as Code into its design process to help companies simplify how they can have better data governance, more secure access control and improved activity monitoring for better visibility.
To learn more, here are a couple of related white papers you can check out:
Data Cloud Security: Secure Access Management
Using Security As Code to Get Away from Privilege Management Toil
