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.