Upcoming Zero Trust Webinar·Register now!
Blog

Unlocking Security as Code by Using GitHub for Managing Cyral Policies

security as code tools workflow

tl;dr

Automated CI/CD is a powerful tool for software collaboration, automated testing, and deployment of cloud applications. This is one of you most powerful security as code tools. Following its development, many cloud native technology companies have also moved to manage infrastructure via CI/CD. By defining infrastructure as configuration files (often called Infrastructure as Code), and deploying those files through the CI/CD pipeline, it is now possible to automate the orchestration infrastructure. As the next generation of this CI/CD progression, Cyral enables integration with CI/CD tooling to automate security for data repositories—all done directly in an organization’s existing CI/CD pipeline. This is Security as Code. By leveraging the collaborative power of Github, Cyral enables you to automate deployment of data security policies, and keep an audit log of all policy contributions. You can learn how to implement this in your own CI/CD pipeline in the guided post below!

Background of Continuous Integration and Development

Software engineers have embraced source code version control for nearly twenty years as the primary means by which software is version managed and collaborated on by teams with many contributors. The open source development of the distributed version-control system git in 2005 by Linus Torvalds and the Linux development community, and just a few years later, the launch of Github, have led to the proliferation of distributed software development. Nowadays, software engineers can contribute and collaborate at will, keeping state managed copies of the entire codebase locally and remotely. We engineers have grown accustomed to the immediacy and convenience distributed source control offers us.

As a result of the widespread adoption and success of git, infrastructure and operational tooling has been built on top, enabling the continual integration and deployment of peer reviewed code. Quite literally, Continuous Integration and Continuous Deployment (CI/CD), has given software engineers seamless and totally integrated control over the entire process from writing new code, to peer review and acceptance, automated tests, and finally deployment. This integrated strategy has empowered modern cloud deployed software developers to rapidly deploy new software, sometimes even several times per day, while simultaneously increasing quality and adherence to development criteria.

Security as Code

In the early days of cloud web applications, swaths of technology startups rushed to build using Ruby on Rails and deploy on Amazon Web Services (AWS). As these startups rapidly scaled up their respective applications, some at exponential rates, the infrastructure often buckled under the load and failed to grow and adapt to the user demand. A famous relic of this era was Twitter’s “Fail Whale,” which sometimes displayed during numerous hours of global downtime. Technology companies needed a way to control and deploy infrastructure rapidly. Recognizing the efficacy of moving code under source control that is fully integrated with CI/CD, they began defining infrastructure in configuration files and managing them under a source controlled CI/CD pipeline. This strategy has reaped benefits in the form of uniform control of infrastructure, audit logs of infrastructure changes, and ease of scaling deployments up and down.

Building on this legacy, Cyral has launched an integration with Github that brings the benefits of version-controlled, CI/CD integrated deployment to the management of data security policies.

Policies in Source Control: Security as Code Tools

The first requirement of implementing a data security policy into a CI/CD workflow is to define the policies in code—Security as Code. Cyral has developed a simple YAML formatted Policy standard to do just this. Below we show an example policy that is managed in a git repository in Github, and we can see that a pull request has been filed. The change in this pull request (see line 15) aims to restrict the number of rows the user ‘bob’ and the group ‘scientist’ can read—in this case lowering the limit from ‘any’ to ‘5.’

Security as Code tools in action—policies to restrict read access in GitHub

Cyral CI/CD Automation: Security as Code Infrastructure

When a policy change is submitted via a pull request, a reviewer can review the proposed changes, and merge them if they’re acceptable. This follows the same pattern software engineers have been using for code contributions for nearly two decades. With Cyral, security administrators can now leverage this same process. Once “Merge pull request” is clicked, the Cyral Github integration is triggered, and the updated policy is received and updated in the Cyral Sidecars so they can start enforcing it immediately.

Prior to merging any policy change, Cyral carries out automated policy checks to ensure that syntax and compatibility evaluations pass. This is represented below in the screenshot with the well known Github green checkmark.

Furthermore, in the well accepted pattern of first merging code to a staging/QA branch prior to merging into a master or production branch, policy changes can be first deployed to a staging environment where integration tests can be run on any applications that may be affected by the security change. In the same way that staging environments have mitigated downtime for cloud application code deployment, they can now ensure that application tests still pass when new data security policies are applied. 

Security as code tools such as Github check the policy and merge it with your code

Audit Trail of Policy Changes

A major advantage of using git for source code management lies in its ability to keep a full audit trail, with identification of who granted which privileges to whom. Besides the forensic benefits of having the audit trail, git introduces the possibility of an approval workflow: a contributor requests a specific policy change, and a reviewer rejects or accepts it.

Additionally, keeping policy changes on branches with a commit trail and compatibility checking ensures that policy contributors resolve their conflicts immediately, just as is required with source code.

Deployment onto Cyral Sidecars

Once a policy change has been merged into the master branch, in this example, and the Cyral Github integration has propagated the update, we can verify that Cyral has started enforcing the updated policy. To demonstrate this, we submit a query that violates the policy. Below we show a MySQL query in a database repository that has the policy enforced. This query happens to violate the policy because it tries selecting many rows:

mysql> select provider_zip_code, provider_street_address from usa.inpatient_hospital_charges limit 100;

Leveraging Cyral’s alerting integration with Slack, an alert is generated in real-time that identifies the violation details, including the offending end user, the database user account, the policy that was violated, and why it was violated.

These violations also matriculate to Cyral’s logging integrations for forensic analysis. Given that security administrators can be alerted about the violation in real-time, they can mitigate any potential damage and avoid having to pore through logs hours or days later.

In summary, Cyral provides an effective means of integrating security policies into a CI/CD workflow, enabling benefits of automation, auditing, and orchestration of deployment of the policy. Sign up for a demo to learn more and get started implementing your own security policies in your CI/CD workflow with Cyral.

Stay Connected