Transcript
This transcript was autogenerated. To make changes, submit a PR.
Hello everyone.
Welcome to Con 42.
My name is, and I'm a DevOps consultant with over 15 years of
experience in the IT industry.
Twilio of those are deeply focused in the DevOps.
My areas of expectations include CICD, automation, infrastructure, asset
code, and cloud native solutions, and more recently, governance and security
within DevOps workflows, what I'm especially passionate about is helping
the teams build pipelines that are not just fast and automated, but also
secure and compliance from the start.
In today's fast-paced DevOps environment, speed and automations are essential.
They often come at the cost of security and compliances.
Traditional manual six can keep up with the velocity of modern software delivery.
As a result is configurations, compliance gaps and the security
risk often go unnoticed until it's too late The solution.
Policy as code allows organization to define and enforce governance rule as a
code, ensuring security and compliances are automated, scalable, and consistent
throughout the development lifecycle.
When integrated with the CICE tools like Jenkins, PAC empowers teams in
the shift left security, catching the issues early in the pipeline
before they reach the pipeline.
So let's dive in.
What are the challenges in the pack?
What are the manual securities that it's failing?
The most alarming statistics in modern DevOps engineering is 60%
of security breaches are cast by the mis config infrastructure.
That means more than half of the security incident organizations face
three are not due to advanced trust or zero to exploits, but because someone
forgot to close a port, left default settings on the production container.
Or misconfigured cloud permissions.
This especially critical in DevOps, where we move fast, automate everything, and
rely heavily on infrastructure as a code.
Small misconfigurations can be replicated across dozens of environments instantly.
That's why integrating security early in the DevOps pipeline
through DevSecOps is essential.
Things like policy as code, automatic configuration, validation, and
continuous monitoring can dramatically reduce this 60 page, 60% each or less.
In short, our goal is not just the faster deployment, but the safer ones.
So what are the challenges?
And the other one is going to be the human error.
Staggering 87 percentage of security issues across modern IT environments
are caused by human errors and DevOps, where teams are constantly deploying,
configuring, and scaling system.
Even a small O site, like a misconfigured S3 bucket,
forgotten an environment variable.
Or incorrect firewall rule can lead to a major breach.
The takeaway manual steps are risky.
Wherever we can eliminate the human error through automation, validation,
and the policy enforcement will significantly reduce the risk.
That's why practices like infrastructure code CI ICD pipeline, security gates
and an automated misconfiguration scanning are no longer an optional.
They are very essential.
The financial impact of security incidents is very massive.
On average organization spends around 3.9 to million
recovering from a single breach.
And this isn't just about fixing the technical issue, it includes.
Downtime that stalls operation on the delivery.
The data loss are corruption in impacting the business integrity, the legal fees,
the fines, and the compliance violations.
Reputational damage that is hard to rebuild, plus the cost of rebuilding
the trust within the customers.
For DevOps team, this underlines the business critical
role of secure practices.
Investing in a secure pipeline's, automated compliances and continuous
monitoring does not just reduce the risk, it protects the bottom line.
So what's policy of code Policy as a code is a practice of writing and
enforcing the security compliances and the operational policies using the
code, which can be version tested and automatically executed just like an
application or an infrastructure code.
Policy as a code is about shifting the compliance as left.
So instead of waiting for the security teams to cast the issues after deployment,
we define the rules as a code and bake them directly into our DevOps workflows.
It's how we scale security.
Reduce the risk and ensure the governance without slowing down the deliveries.
So policy as code policies are issued written in mission readable formats
such as Jason or YAML or Rego or open policy agents, each format
has its strengths and drop access.
For example, Jason and Yam L are popular for configuration files while Rego is a
policy language tailored to validate the complex policies and what's the benefit.
Consistency, automation and traceability automates governance,
ensuring the uniform policies are applied across the entire pipeline.
It reduces the human intervention and the chances of error leading to faster,
more secure deployments, and it allows to frame the track, the policy changes,
ensuring the accountability and the visibility into the government actions.
So let's discuss about the policy as a code throughout the DevOps lifecycle.
As a developmental stage, our goal is to catch security issues as
early as possible before code even reaches the staging or production.
This is where policy as code comes in.
By defining our security and the compliance rule in the
code, we can integrate them directly in our DevOps workflows.
So the moment the developer writes or commence the code, it's automatically
checked for violations like the open ports, unencrypted data or
the noncompliant address confis.
If something violate its policy, the pipeline fail fast.
If it passes, we move forward.
This approach ensure we are building a secure software from the day
on and not retrofitting it later.
Once the build is done, sorry.
Once the code is written uncommitted, we move to the build station where
things can start to get packaged.
This is a critical point to validate where we are actually building first.
We are on the software compostion analysis tools to identify any vulnerable
libraries or outdated packages.
These are common sources to exploits.
Next, we scan the container image for misconfigurations, like
running as a rule, unnecessary port open or insecure base images.
We then use the policy as code to enforce our bill standards if an image
does not meet of a security criteria.
We break the build.
This ensures that only secure complaint artifacts move forward.
In the test stage, our focus is on validating the security posture
of an application itself, not just the code or a container.
We must run a mix of tools like SAST for scanning the source code for a security
box, DASD for checking the vulnerabilities in the running apps, IASD for running the
insights during the test executions, but.
Testing isn't enough.
We need to enforce policies.
That's where policy as code plays a critical role.
It allows us to define the thresholds like no critical vulnerabilities
or 90% security test coverage, and an automatically blocked
bills that don't meet them.
This ensures that we are not just testing, but enforcing a minimum bar for
a security quality before ever deployed.
In the deploy stage, it's essential to ensure that the infrastructure itself
is secure and compliant before anything.
We use the infrastructure code tools like Terraform or a cloud formation, or define
our environments, or before we provision
policy as a code is integral here.
It allows us to define security rules in the code and automatically enforce
them, making them an only complaint.
Infrastructure gets deployed.
If something offs like an insecurity S3 bucket of an improper IA permissions,
the deployment fails by shifting left security to the deploy phase and
automate compliances be drastically reduce the risk of misconfiguration and
unauthorized access in the monitor stage.
Detect and alert our runtime policy violations does not end with just
deploying the code or infrastructure.
We need to keep the constant watch on runtime operations to detect and
respond to the security violations in the real time by monitoring
both application infrastructure.
We can catch issues that occur like the deployment, like an unexpected
configuration change, or an unauthorized access to the sensitive data policy
as a code continues its role here.
Providing runtime checks that enforce security rules even
after the resources are live.
If the policy violation occurs, say if a server start using a
weak encryption or an unauthorized user tries to access the resource,
the system alerts us immediately.
These realtime alerts combined with the tools like SIEM systems for a centralized
logging enable a rapid response to any violations allowing us to respond
to incidents before they escalate.
So here comes the real question.
Why Jenkins for policy as a code?
It's because of the factors like ecosystem integration, pipeline
flexibility, community support, and established infrastructure.
Jenkins is well known for its ability to integrate with various different
tools, making it a very easy to integrate policy enforcement without needing an
overall of existing infrastructure.
Jenkins provide flexibility.
By allowing policy checks to be inserted at any stage in the DevOps pipeline,
whether it's during a code checking or build, or testing or deployment.
Jenkins offer with larger user base and extensive documentation,
which ensure that there is an ample community support and the resources
available when implementing the bank.
Jenkins has already widely deployed many organizations, so implementing
PAC and Jenkins leverages the existing infrastructure and tools that many
DevOps teams are already using.
And so how it's done, how to implement the pac.
Storing our policies in a source control like GI gives us a powerful way to
track the changes, manage the versions, and keep a clear audit trail for the
compliance on the security purposes.
By version controlling our policies, just like application
code, we can see who changed.
What and when, which are essential for the compliance audits.
We can even roll back to the previous versions of the policies
if needed, and if ensures the transparency and the accountability
in how policies evolve over time.
Collaborations become much easier because a team can propose review and approve
the changes to the policies directly in the version control repository.
And of course, by trying the policies back act as a policy, as code
frameworks like open policy agents.
We can automatically enforce these policies in our CICD pipelines.
To integrate the policy as a code in our CICD pipelines, we installed the
policy engines like A-O-P-A-O Ps, or open policy agents or con contest
directly into the Jenkins plugin.
This allows us to enforce the policies automatically whenever code
or infrastructure changes are made.
The open policy agent provides the flexible engine for writing the policies
in the Rigo, which can cover a wide range of compliances and the security checks.
The contest on the other hand, is perfect for enforcing the
policies on a configuration files such as the A ML or json.
Once the policy engines are installed, we configure the
Jenkins to run these policies at a specific points in the pipeline.
Usually during the build or deployment, if any policy violation
are detected, the bill fails, and then team gets an alert preventing
noncompliant code from going live.
This seamless integration of a policy as a code ensure we have a
transparent, automated and a reliable enforcement process within the dev
workflows to integrate the policy as a code in our CI ICD pipeline.
We start by defining the pipeline stages in our Jenkins file.
These stages control the flow of the pipeline.
Include building, test, and the deploy At the early critical checkpoint in the
pipeline, we insert the policy validation slips to make sure the code infrastructure
and the deployment configuration meet our security and compliance standards.
Before the build, we an open policy agent policies to validate the code itself.
After the testing, we run the contest to check for the compliance
issues in the configuration files and before the deployment, we
validated the infrastructure and the deployment configurations
to ensure no misconfigurations are going into productions.
If any policy fails, the pipeline automatically stops preventing
non-compliant code from moving forward.
This issues, we enforce security and compliances consistently
throughout the entire pipeline.
One of the most important decisions in integrating the policy as code
is how we handle the violations.
Should the pipeline stop immediately or should it keep continuing if the
violation is critical, such as a security vulnerability or a compliance breach.
We should stop the pipeline to prevent non-compliant code from being deployed.
This is the default behavior for the critical security policies.
For non-critical issues like a code style violations or minor configuration
issues, we must report them the violations stopping instead of stopping the pipeline.
This keeps the process moving while flagging the issues for the future review.
The beauty of policy as code is that we can customize
failure actions per policies.
For example, a security policies might hal the pipeline, but a performance policies
might only log and report the violations.
This flexibility ensures we can balance the security enforcement
and develop an agility, allowing us to maintain a high quality without
unnecessary slowing down the deliveries.
So what's the popular.
Policy enforcement tools.
It's examples like a op contest, HashiCorp Sentinel.
So what's an open policy agent?
One of the most popular tools for a policy as a code
enforcement is open policy agent.
It's general purpose policy engine that can validate and enforce
policies across multiple system, and it uses a declarative languages
called rego for writing the policies.
The key advantages of OPA is its flexibility.
It allows you to centralize the policy enforcement across multiple platforms,
reducing the complexity of managing the policies across the diverse technologies.
Additionally.
The open policy agent integrates seamlessly into the existing CICD
workflows to enforce policies during the build, test and the deployment stages.
By using the open policy agents in the policy as a code approach, you are
ensuring that policies are consistently enforced, which helps reduce the risk
and ensure compliances across your organization's entire infrastructure.
Contest is a specialized tool for the testing configuration file
against the defined policies.
It's particularly useful for validating the YAML and the JSON files, which
are commonly used into the tools like Kubernetes, Terraform, and Health.
With contest, you can write the policies in rego and apply them
to your configuration files.
This ensures that your configurations are in line with your organizational
standards before they are deployed.
Contrast integrates easily with the CICD pipelines.
During the build or deploy stages, it can automatically test your configuration
files, block the non-compliant configuration, and provide detailed
feedback for the developers to quickly address the issues using comp as a
part of your policy as a code strategy.
Issues that configuration across your enter environment or secure.
Compliant and consistent.
The HashiCorp Sentinel is a powerful policy as a code tool embedded directly
within the several HashiCorp product.
Unlike other standalone policy engines, Sentinel is natively integrated into
the tools like Terraform Vault and Console making it ideal choice for
the in infrastructure governance.
The integration of the Sentinel within the HashiCorp products ensure
that the policies are automatically applied and enforced as a part
of normal deployment process.
Without the need for the external tools.
It also provides a scalable solution to the policy enforcement across
the cloud native infrastructure.
Decentralized policy enforcement ensures that the governance is
consistent and automated across the environment, saving time and reducing.
The manual oversight.
So here comes the real world policy examples, like preventing
public S3 buckets, enforce resource tagging and container security,
and identity and access management.
Policy as a code can be used to enforce the security policies that
prevent exposing the sensitive data, such as rejecting AWS
infrastructure, changes that might have.
An SD public pocket described a policy that requires a special tax to be applied
on all cloud resources, making it easier to track and the managed cloud costs.
The policy as a code can block the deployment of a container that's
either have known vulnerabilities or configured or run as a route,
reduce the attack surfaces.
Fact ensures that the IDD and access management policies follow
at least the privilege principle, ensuring the users or a service only
have the permission they need it.
Let's quickly walk through of a sample.
Jenkins Pipeline with the policy as a code.
So as you see, we have multiple different stages.
First stage code is checked from the version control, then use contest to test
the Terraform files for policy violations before resources are provisioned.
We had another stage to generate the Terraform plan.
Which outlines the infrastructure changes and the Terraform plan is tested again
against the policies to ensure the compliances and the deploy stage only if
the policy is passed, the infrastructure changes are deployed using the Terraform.
How to integrate the pack into the deployment development workflows.
One of the best ways to integrate the policy as a code into the development
workflows is by providing instant policy validation, directing within the I IDs.
This means that as a developer write code, whether it's an infrastructure
as a code, like a Terraform, or an application configuration like a
Kubernetes yaml, they get real time feedback about whether there are changes
are compliant with security or compliances and other organizational policies.
Tools like VS.
Code Intelli and other popular IDs allow developers to install.
Plugins that validated configuration or code against the predefined policies.
This provide immediate feedback on the issues like insect configuration
or non-compliant resource definition.
Allow developers to resolve the issues instantly before moving forward.
The benefits are very huge.
Increased productivity because developers don't have to wait until
the pipeline runs to find out if there is an issue improved, code quality
as a violation, or cut early leading to a better and more compliant code.
The faster delivery asset development process does not get.
Delayed by the last minute policy violations or a manual check.
By bringing the policy enforcement right into the development environment,
we make sure that policies are continuously enforced in the real time,
reducing the friction and ensuring the consistent compliant deployments.
The pull request enforcement is a powerful way to integrate the policy as a code into
the development workflows by automatically running the policy checks during the code
reviews, you ensure that only compliant code and the secure configurations
are merged into your main branch.
Before a pool request is approved, automated tools such as run policy
checks that validate the code or infrastructure against your
predefined security compliance, and the best practices policies.
For example, the policies can ensure that the Kubernetes CML file contain
the necessary resource limits or data, terraform code compliance
with the access control policies.
Benefits are clear.
Prevention of non-compliant changes by catching violations Early in
the poll request process, you can prevent non-compliant code
from making it to the production.
The streamlined code reviews.
This reduces with the burden on the reviews since the policy checks that are
automatically handled, letting them focus on the logic and the design of the code.
As every change is checked against the policies, you maintain a high
level of consistency in the code quality and the security practices.
Integrating PAC into a pool request process helps ensure that the development
process is not only fast, but also secure and compliant, which the key
delivering high quality software.
The critical component of the integrating policy as a code into the development
workflow is the use of pipeline gates.
These gates are automated policies.
Enforcement points into the CICD pipeline, that block non-compliant
changes from progressing to the next stage, whether it's a build.
Test or deploy the gates ensure that only compliant code and
the infrastructure gets through.
For example, in the build stage, we can configure the pipeline to
check the security vulnerabilities like insecure, hot coded credentials
or compliance violations, such as missing required resource limits
in the Kubernetes YAML files.
If the violation is detected, the pipeline stops.
Preventing the deployment from the non-compliant changes.
The main benefit of the pipeline gates is that they automatically enforce policies
as a key stages of the pipeline, reducing the need of a manual interventions and
ensuring compliances at every step.
This provides faster feedback to the developers so they can fix issues.
Earliest consistency in enforcing the policies across all the environments.
Most secure under compliant code base by ensuring the only policy
compliant code can be deployed.
By incorporating pipeline gates into the CICD pipelines, you are ensuring that
the every piece of code that reaches the production is properly vetted
for security compliances and the best practices providing stronger governance
and the reducing risk The compliances.
Reporting is a key factor.
The key aspect of a policy as a code that ENS ensures you are
prepared for regulatory audits.
These automated reports track and they document policy violations
in the real time and they include the essential information such as
timestamp, who made the change, and what specific policy was violated.
This level of documentation is invaluable when it comes to providing
a regulatory compliances in the audits.
The benefits of complying.
Reporting includes the ability to generate the auditable reports without
manual efforts, a proven track record of a compliance with the industry
regulations such as GDPR or hipaa.
The ability to continuously track and improve the compliance approach
over time by reviewing audit data and taking proactive measures to
correct the policy violations.
By automating compliances reporting, you ensure that your organization can
always prove compliances and quickly respond to regulatory requirements
with up to date accurate reports.
What should be done to we get started today?
So start by identifying the most important security and the compliances
policies, those that address the most common or critical security risk.
The recommendation is choosing the tools that work with the existing stack.
Example, the open policy agent for the most cases.
And should these tools integrate seamlessly into your pipeline, always
start small with the non-production environment or with the policies set to
one only mode before fully enforcing the heart failures as a measure of success.
Expand the policies.
Always reassure the audience that policy as a code is an IT process.
Security improves as more policies are gradually implemented as we go on.
That we all hope we had a good touch base with the policy
as a code and it's useless.
Please feel free to reach me or email my profile for any assistance
or help needed in the future.
Let's get the environment safer.
Policy.
Thank you for your bye.