Tag: policy as code

  • Declarative Compliance With Policy-as-Code and GitOps

    Declarative Compliance With Policy-as-Code and GitOps

    In recent times, the quest for greater agility, faster releases, enhanced scalability, security and performance brought forth the advent of several automation tools, technologies and frameworks. Software development has evolved considerably over the years to mitigate these challenges.

    Monoliths have been split into microservices for improved scalability, maintenance and faster releases. Since DevOps is adept at bridging the gap between development and operations teams, now these two teams can work together to improve productivity and speed up release cycles.

    The Need for Compliance

    One of the critical strategies for business success is to stay compliant since processes are always improving and evolving. Compliance ensures that your DevOps processes and practices are consistent and meet regulations or regulatory standards.

    An organization with a compliance-driven DevOps culture can cut down on operational costs, improve efficiency and reduce risks considerably.

    What is Declarative Compliance?

    Declarative compliance is defined as the process of managing and enforcing compliance in which policies are defined using code, and the system’s desired state is declared rather than explicitly programmed. To enforce compliance policies, you don’t write scripts or programs; instead, you use a high-level language or configuration file.

    Declarative Compliance provides several benefits:

    • Increased efficiency
    • Better managed compliance
    • Minimized risk of human errors
    • Enhanced security
    • Faster deployment
    • Better collaboration

    With declarative compliance tools, the system’s state is defined as a set of policies, and the tool makes sure it matches the desired state. The tool will automatically fix anything out of compliance, bringing the system back into compliance if there’s a deviation.

    Tools for Declarative Compliance

    Some of the popular declarative compliance tools are:

    • Open Policy Agent (OPA)
    • Terraform
    • Kubernetes Policy Controller
    • Chef Compliance
    • AWS Config

    Declarative Compliance for Infrastructure and Application Deployment

    Often, declarative compliance is used in infrastructure management and application deployment, where policies are written as code and enforced across multiple environments. In addition to managing compliance at scale, declarative compliance tools ensure that the system’s desired state stays consistent across multiple systems and applications over time.

    With declarative compliance, organizations can manage compliance more efficiently, effectively and securely since they can define policies as code and enforce them automatically. In addition to reducing errors, downtime and security breaches, this approach enables organizations to stay compliant and maintain their system consistently.

    Introduction to Policy-as-Code

    A policy-as-code approach allows you to write programs that govern security, compliance and rules throughout your application’s life cycle. It entails defining and applying code to manage and automate policies. It shares the same ideas as infrastructure-as-code (IaC) and other DevOps practices like continuous integration and continuous delivery (CI/CD).

    A policy enforces constraints and restrictions to prevent unauthorized access to resources such as databases, storage, services, etc. By codifying policies, you can enforce rules and constraints throughout the development life cycle to prevent non-conforming resources from being deployed by integrating these policies into the software development life cycle.

    compliance policy-as-code

    Figure 1: Policy-as-Code at work!

    Why Policy-as-Code?

    Typically, businesses have the required processes, tools and procedures to guarantee the deliverable’s quality. Performance, scalability, ease of use and accuracy are typical quantifiable quality metrics used to ascertain the quality.

    You can examine the quality of your application using these metrics, but a manual procedure will take time and is prone to mistakes. A better alternative is to leverage policy-as-code.

    The traditional policy enforcement processes have certain drawbacks. It is challenging to perceive that your policies would be entirely adhered to, i.e., they will not be broken. It is cumbersome to check against a list of policies manually.

    Moreover, the traditional policy enforcement method cannot scale in today’s agile world, where organizations have been growing continuously with more and more employees, services and teams.

    Here are the key benefits of policy-as-code at a glance:

    • Faster and more efficient deployments
    • Automated governance, approvals and policy enforcement
    • More reliable and secure applications
    • Centralized policy management
    • Leverages version control
    • Better visibility of policies
    • Enhanced collaboration

    How Does it Work?

    Policy-as-code involves three key elements:

    1. The policy itself, which contains the required code to model the decision-making process
    2. The data and information about the environment, service or application
    3. The query that is responsible for triggering the decision-making process

    Here’s how policy-as-code works:

    1. Policies are defined as code in a human-readable format
    2. These policies are then translated into machine-readable code using Rego or HCL
    3. The policies are integrated with the IaC pipeline
    4. A policy engine evaluates the infrastructure and the application resources against these policies
    5. The policy engine accepts the policies as input, processes them and then produces a query result
    6. The policy engine reports violations (if any) to the respective stakeholders, such as the development or security teams
    7. If violations are reported, the necessary remediation is performed automatically or manually

    Types of Policies

    • Security policies: Security is enforcing adequate technological controls to safeguard company assets.
    • Compliance policies: Compliance policies are designed to help organizations adhere to governance standards. Typical examples include PCI DSS, GDPR, HIPPA, etc.
    • Operational excellence: This encompasses policies pertaining to service degradation or interruption.

    What is GitOps? How can GitOps Help With Compliance?

    GitOps is a subset or extension of DevOps encompassing a collection of practices that can simplify deployments using Git. It is an operating model for cloud-native applications that leverages Git as a single source of truth for declarative applications and infrastructure. Using GitOps, you can implement a standardized policy-as-code approach across your CI/CD and GitOps pipelines.

    The key principles of GitOps are:

    • The state of the system is captured and stored in a Git repository
    • The entire system is configured declaratively
    • Automated deployment

    You can create policies in Git and store them in a particular repository, which is essential since Git offers sophisticated change management tools like version control. Only the compliance team would have admin access to the repository.

    It’s easy to enforce policies with Git, and you can apply them to any execution engine, like CI or CD. With GitOps, you can audit and document every action that affects data consumption.

    You can expose system changes, optimize deployment and use a version-controlled infrastructure. By managing compliance with GitOps, you can make sure that the changes are visible, verifiable and auditable.

    GitOps

    Figure 2: GitOps at work!

    Using GitOps as the Execution Engine in a GitOps Process

    There are several benefits to using GitOps as a process execution engine, including:

    • Increased automation: GitOps automates software delivery, reducing manual intervention and increasing deployment accuracy and speed.
    • Better transparency: GitOps records all changes to the system in a transparent and auditable way so that you can track compliance easily.
    • Maintaining consistency: GitOps keeps the system in the desired state defined in the Git repository, reducing non-compliance risk.
    • Fosters collaboration: All changes to the system are made through the Git repository, so GitOps encourages collaboration across teams.

    Using Policy-as-Code and GitOps: Policy-Based Compliance

    By using GitOps and policy-as-code, teams can manage compliance-as-code in an auditable, declarative way and enforce it via GitOps, ensuring that the desired state is always maintained. This can help your teams to codify compliance requirements as code, store them in version control and automatically enforce them through GitOps.

    Organizations can improve the consistency and reliability of their systems by defining and enforcing compliance requirements using policy-as-code and managing their deployment processes with GitOps. While this can minimize compliance violations, it can also maximize efficiency.

    By following policy-based compliance declaratively, businesses can define policies as code and enforce them automatically and repeatedly. By adopting such an approach to compliance management, you can better manage compliance in complex systems in a consistent, scalable, agile, transparent and collaborative manner.

    For example, you can leverage policy-as-code to define policies for infrastructure provisioning and configuration management to ensure that the infrastructure complies with organizational policies and industry standards. Typical examples are defining policies for network configuration, access control and resource allocation.

    Use Cases: Using Policy-as-Code and GitOps in a Production Environment

    Infrastructure Provisioning

    Open Policy Agent (OPA) can define policies for infrastructure resources like AWS Elastic Compute Cloud (EC2) servers. You can use GitOps to manage the deployment of infrastructure resources by storing IaC files in a Git directory. When the IaC files are changed, GitOps is adept at automatically deploying the changes while OPA checks for policy compliance.

    Deployment

    You can use policy-as-code tools such as OPA to create application deployment policies requiring specific security settings, while GitOps manages the application deployment by storing manifests.

    Manage Kubernetes Clusters

    You can leverage policy-as-code to better manage your Kubernetes clusters. So, you can write your code to define policies to manage Kubernetes resources, such as nodes, pods, clusters, etc., declaratively.

    Compliance Management

    You can use policy-as-code to establish and implement rules and regulations, such as those pertaining to security, to help businesses ensure that their systems comply with industry regulations and standards.

    OPA can be used to set compliance policies, like restricting access to sensitive data to authorized users only. You can use GitOps to manage the deployment of compliance policies seamlessly.

    Trusted Delivery: Policy-as-Code Integrated With GitOps Workflows

    Trusted application delivery is a software delivery approach emphasizing security and trust in the software supply chain. This ensures that any software delivered to the clients is devoid of security flaws, malicious code and other attacks.

    This approach prioritizes security and trust at the development, testing, packaging and deployment stages and integrates security and compliance checks into the GitOps pipelines. This quality check reassures clients about the product’s quality and ensures that any modifications adhere to predetermined rules and principles.

    Trusted application delivery allows for quick deployment while securing apps with automated guardrails. These guardrails are implemented using policy-as-code. By enforcing these guardrails, you encourage frequent deployments while ensuring that the reliability and security of the application are not compromised.

    Conclusion

    Declarative compliance with policy-as-code and GitOps is a best practice for achieving greater compliance, reliability and agility in software development and deployment processes. You can simplify defining and enforcing compliance policies using declarative configuration files and automation tools. Using Git as the single source of truth for all configuration changes, an organization can achieve greater efficiency, visibility and auditability in the compliance process.

  • Introduction to Cloud Custodian

    Introduction to Cloud Custodian

    Organizations continue to increase their footprint in the cloud. Yet, applying governance and enforcing policies across multiple cloud environments at scale is a challenging endeavor. Organizations typically have governance policies written in English, but translating them into enforceable code has historically required some custom workarounds. In the same vein as infrastructure-as-code (IaC), DevOps engineers now seek a similar GitOps approach to implement shared policies across cloud-based workloads.

    Cloud Custodian is one such toolset that can manage and enforce cloud policies in a standardized format. Using Cloud Custodian, a Cloud Center of Excellence has the building blocks to create policies for security governance, development guardrails and cloud cost optimizations. The free, open source project, which has been steadily evolving for years, recently gained its incubation status with the Cloud Native Computing Foundation (CNCF) and to date boasts over 350 contributors on GitHub.

    I met with Kapil Thangavelu, Cloud Custodian creator and maintainer and CTO at Stacklet, to learn more about Cloud Custodian and what features we should anticipate from the project in the near future. Below, we’ll provide a comprehensive introduction to Cloud Custodian, exploring its history, how to use it and its core benefits. We’ll also analyze a few sample policies to showcase how Cloud Custodian functions in practice.

    What is Cloud Custodian?

    Cloud Custodian got its start as an internal tool developed within Capitol One toward the end of 2015, explains Thangavelu. At the time, engineers were grappling with the newfound realities of managing the cloud at scale and realized that having one-off ad-hoc policies across teams was causing friction. “It’s really hard to manage and enforce policies at scale,” says Thangavelu. So, engineers toyed with creating a more GitOps approach to policies around governance and security that could be run as an internal SaaS solution.

    Thus, Cloud Custodian was born. The YAML DSL tool allows you to easily define rules to manage cloud infrastructure. It can offer real-time enforcement and produce event-based responses. For example, you can create policies that require tags on resources or one that turns off instances during off-hours. Or, a policy could prevent a developer without the proper privileges from accidentally making an open load balancer. Cloud Custodian supports AWS, Azure, and GCP and policies are specified to a resource type, whether it’s EC2, ASG, Redshift, CosmosDB or a PubSub Topic.

    Thangavelu describes Cloud Custodian as a bunch of Lego bricks that developers can pick up to build guardrails in arbitrary ways. Instead of shipping with canned rulesets, “Cloud Custodian makes customization itself a first-class citizen,” he says. Capital One open sourced the project and contributed Cloud Custodian to CNCF in August 2020.

    Example Policies

    Cloud Custodian comes with a library of actions and filters. Let’s take a look at a few example policies across the three main cloud providers. But first, to install Cloud Custodian from PyPI, you can initiate the following command:

    $ python3 -m venv custodian
    $ source custodian/bin/activate
    (custodian) $ pip install c7n
    

    Let’s consider an example policy that would improve security hygiene on AWS. Below is one such policy that creates a CloudWatch Event to be triggered anytime a user logs in from an invalid IP address. This could be used to ping a security administrator to investigate. With this rule, it’s also possible to turn on an auto-remediation function.

    policies:
    
      - name: invalid-ip-address-login-detected
        resource: account
        description: |
          Notifies on invalid external IP console logins
        mode:
           type: cloudtrail
           events:
              - ConsoleLogin
        filters:
          - not:
              - type: event
                key: 'detail.sourceIPAddress'
                value: |
                   '^((158\.103\.|142\.179\.|187\.39\.)([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
                   \.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))|(12\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])
                   \.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))$'
                op: regex
        actions:
          - type: notify
            template: default.html
            priority_header: 1
            subject: "Login From Invalid IP Detected - [custodian {{ account }} - {{ region }}]"
            violation_desc: "A User Has Logged In Externally From A Invalid IP Address Outside The Company's Range:"
            action_desc: |
                "Please investigate and revoke the invalid session along
                with any other restrictive actions if appropriate"
            to:
              - CloudAdmins@Company.com
              - SecurityTeam@Company.com
            transport:
              type: sqs
              queue: https://sqs.us-east-1.amazonaws.com/12345678900/cloud-custodian-mailer
              region: us-east-1
    

    Next, let’s consider a policy that would add some degree of governance for developers working on Azure. One simple yet popular policy involves tagging the ownership details to individual resources. This policy, therefore, will tag all resource groups with the creator’s email address:

    policies:
      - name: azure-auto-tag-creator-resource-groups
        resource: azure.resourcegroup
        description: |
          Tag all existing resource groups with the 'CreatorEmail' tag; looking up to 10 days prior.
        actions:
         - type: auto-tag-user
           tag: CreatorEmail
           days: 10
    

    Finally, let’s consider a policy that could aid in cost optimization on GCP. Below is a sample policy to enforce minimal CPU utilization for autoscalers on GCP. Implementing such a policy could help avoid underutilization to combat rising cloud costs.

    vars:
      min-utilization-target: &min-utilization-target 0.8
    policies:
      - name: gcp-autoscalers-enforced
        resource: gcp.autoscaler
        mode:
          type: gcp-audit
          methods:
            - v1.compute.autoscalers.insert
        filters:
          - type: value
            key: autoscalingPolicy.cpuUtilization.utilizationTarget
            op: less-than
            value: *min-utilization-target
        actions:
          - type: set
            cpuUtilization:
              utilizationTarget: 0.8
    

    Benefits of Cloud Custodian

    By automating a lot of the tedious policy management away, Cloud Custodian could reduce risk and accidents through more streamlined cloud governance. “It solves the natural problems when infrastructure is in everyone’s head,” says Thangavelu. By aggregating ad-hoc scripts and unifying policies across an organization, you could immediately instigate new rules without manually reminding all members of an organization, which could take years.

    For those familiar with Open Policy Agent (OPA), you may notice some overlap in the objectives, as both are engines for enacting cloud-native policies. Compared to OPA, Cloud Custodian has some developer experience perks. For one, you don’t have to use Rego, as the policies are written in YAML, which is a familiar configuration language for DevOps engineers. Cloud Custodian uses abstractions on event runtimes for each cloud provider. Furthermore, compared to OPA, you don’t need to bind the engine for a particular problem domain, says Thangavelu, as Cloud Custodian is specifically bounded to cloud governance and management.

    Cloud Custodian is also battle-tested. Many big names are using it in production, including Capital One, HBO Max, Intuit Inc, JP Morgan Chase & Co, Siemens and Zapier. Across its adoption, the tool tends to either be utilized by a Center of Cloud Excellence, security teams to conduct reporting or reveal real-time incidents or the CFO to direct cost optimizations.

    Future of Cloud Custodian

    Cloud Custodian maintainers describe the project as a consistent firehouse. Since the project tracks changes in all cloud provider resources in real-time, it’s quite a dynamic toolset. In addition to monthly updates, users can expect many additional updates on the horizon, including support for Tencent Cloud as well as additional Kubernetes support. Additional work is being done around shift-left capabilities to meet the developer where they are, says Thangavelu.

    For more information, check out the Quickstart Guide to Cloud Custodian, or view the project roadmap here.

  • Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    Growing Adoption of Compliance as Code and Policy as Code – Techstrong TV

    As DevOps has matured and more organizations have adopted an infrastructure as code methodology, alongside an increased importance of security, we are seeing compliance as code and policy as code being adopted by many organizations. Progress Software’s Chef products are helping lead this trend. The video is below followed by a transcript of the conversation.

    Alan: Hey, everyone. Thanks for joining us on another TechStrong TV interview. I’m really happy to have – well, it’s the first time I’ve interviewed him here on TechStrong TV, but Charlene has had the pleasure of having Prashanth on before. Let me introduce you and I’m gonna do my best on his name, I apologize. Prashanth Nanjundappa. Is that close, Prashanth?

    Prashanth: Yes. Prashanth Nanjundappa. That’s close. 

    Alan: All right. Prashanth is with Progress Software, where he’s a VP of product, isn’t it? 

    Prashanth: That’s correct. 

    Alan: And we’re going to talk a little bit about today, we’re gonna talk a little bit about, you know, compliance’s code, you know, in this shift left kind of mode, but also the whole maturation of the DevOps space, etcetera. But you know what, Prashanth, as we spoke about off camera, this is your story to tell. Right? This is your kind of thing. Let’s, you know, talk about things that are important to you. Why don’t we, you know, tell us what what’s kind of important to you these days? 

    Prashanth: First of all, let me thank you. Thank you, Alan and TechStrong TV. This is a great opportunity to actually talk to many of the people who are using our products. Right? I am currently leading the head of product management for one of the business units in Progress, which is managing Chef line of business. We acquired Chef on board about 1.5 years ago. And this is my first foray into managing or building DevOps and SecOps tools. And that was a disadvantage, and also an advantage. 

    I got to talk to about 150-odd customers because I didn’t know much about this space. So the best way to learn about it is talking to our customers and talking to people who are experts in this domain. And that kind of got me really, really knowing about how these large enterprises are even tech companies are investing a lot in automating their day-to-day needs and adopting DevOps and their SecOps as technology practices, bringing those practices in their organization, and using tools like Chef to make just not their teams efficient, but also to increase time-to-market and reduce the risks of their business. 

    And the reason I’m talking on this, I think your target audience are the people who listen to this stuff. Your videos are the kind of practice notes that I talk day and day out all the time. They give the feedback which has helped us graph out the roadmap for years to come with Chef product line. 

    Alan: Absolutely. And you’re right. That is our audience. Right? Quite frankly, you know, when I launched DevOps dot-com eight years ago, Chef was one of the giants in the – you know, pioneer in the DevOps space, and that was our audience. But you know, over the years, we’ve seen this shift, if you want to call it shift left. It’s not necessarily a shift left, but we’ve seen an increased emphasis on security. And, you know, security’s partner in crime in many ways is compliance. 

    But as we’ve automated more, as we’ve gone faster and try to be better, faster and better, right, we’ve recognized the same way we’ve automate in DevOps deployment, we need to automate more when it comes to security and compliance. Right? And that’s been painful at times quite frankly. It’s not necessarily easy. 

    Prashanth: Oh yeah.

    Alan: Let’s talk about, you know, where the kind of hard parts are and how companies like Progress are helping us overcome that. 

    Prashanth: You’re spot on. It’s hard. It’s unnecessary evil as some people say but I think that is changing. So before that, taking a step back, why is security and compliance required? I think the need of security is well understood, but compliance data has been historically three primary reasons. Either they are regulated bodies who keep looking out who is complaint, who is not complaint. Every few months or ever few years, they publish a new set of standards, which give a perception to companies or tech companies that they need to adhere to that. 

    And that then get complemented by either the regulated sectors like banking and financial, credit card, or hospitality, healthcare, where security, privacy, all these things that are of most concern. And they look back at these regulatory bodies who have been publishing these specifications. These two kind of go hand-in-hand. And I tell you, there is a third-dimension, who are the customers who are using the products. They look at these regulatory bodies who turn out the specifications and also the regulatory. They say if I want to buy a product from you, I want it be certified. I want it to be compliant to this. 

    So these complaint as a need to operate in such industries. But I think it is moving a little from the basic necessity of, you know, being compliant to making sure that my development is fast-paced. Today, if you look at every – there are so many companies, Uber or something, Airbnb, or something, Yelp or something, and this used to be in the consumer sector, but it also coming into regular segments like banking, financials like that, Robinhood like companies have normalized trading, and they have made sure that anyone can launch a product. 

    So even tech chains, they have to adapt to this fast-paced market and bring their products not just fast into the market, but also adhere to the compliance standards, compliance specification, and make sure that whatever they launch is secure. And that is where automation comes. And that is where as a code paradigm came. You’re quite familiar with the evolution of how infrastructure as code and DevOps involved. There the codification of infrastructures have involved because they wanted to make sure that whatever gets developed is automated, and they test well in advance. 

    I think the same mindset is coming here because are there different bodies, developers, Ops team, and security teams. All of them generally speak in completely different languages, but if you want them to bring together to actuate the time-to-market, they need to speak one code, one language, and code seems to the most common, most acceptable language. And once they make a code, it falls into the DevOps sector. You can test it. You can repeat it. You can make sure there are checks and balance to make sure you flag, you audit everything. 

    But I think that mindset, and also DevOps has made compliance as code acceptable. And we are seeing more and more option. And that is ability of success for the traditional organizations to move in a fast pace. And new companies, they don’t even see other options as options. They take it as default option because this helps them past development. I don’t know if it makes sense. 

    Alan: No, it makes perfect sense. I mean it’s also a life a lot of our people are living day-to-day right now. Right? So the security person in me, and Prashanth, I was in security infosec, as we called it before, cyber sec, whenever I worry about compliance, I hear about compliance, I immediately start thinking, you know, am I dumbing down my security for compliance sake? Right? Because sometimes when we do compliance, it’s kind of, you know, I could call it least common denominator security. It’s like the lowest bar. Right? 

    Prashanth: Right.

    Alan: And a lot of people say, “Okay. I’m compliant. I must be secure too.” But they’re not. Just because you’re compliant doesn’t necessarily mean you’re secure, whether you’ve, you know. Compliance, as they say in Las Vegas, it’s a fine beginning. Right? But it’s not the mean to the end. So how do you, you know, as a compliance’s code type of provider, how do you make sure that your customers understand, okay, since you’ve done step one, but you still need to do step two and three. 

    Prashanth: Exactly. This is a very important distinction we also took a while to realize. Right? So there are three pillars: infrastructure, compliance, and security. So infrastructure is basically – I mean we can argue what is foundational, but you build your application and that’s where automation is required of infrastructure. Right? And then if you want to operate in regular tech sectors, if you want to be – not lose the competitive advantage with other players, you need to be compliant. 

    But security is something, which is fundamental. Right? You don’t realize until there is a breach, or until there is an impact on business. But, you know, these days, unfortunately, that is not very uncommon. We are seeing so many companies being exploited because of very, very basic mistakes like opening their port 80. Right? Exposing a port 80, or leaving their S3 buckets unencrypted. Right? 

    So many of these things are misconfigurations, or many of these things would have been covered or not happened if they had held to some of these standards. Two such bodies which offered a large specifications of best practices. Of course the primary takers of that is compliance. But those act as a foundation to security infrastructure. So we help our customers in obviously infrastructure and compliance, but we have started helping them in secure infrastructure as well. 

    Well, they have to look at infrastructure whenever an application passes through the CI/CD pipeline at each point in sort of just checking for the functionality using the right tools, some of the tools that we built, and some of the tools are available in their ecosystem. They can secure it. It can harden an image. For example, within Progress, there are teams which are using our Chef software to make sure that every image that gets into Artifactory, the Docker container gets into Artifactory isCIS specification, and other qualities that are specific. They don’t let it get into Artifactory without going through this. 

    So I think that is very much possible, and that is the education that we are giving and helping our customers, and that’s a two-way process. Right? Because we maturing in security. So as we engage with our customers, we are learning some of the shortcomings and the tools, and we are bringing back in the quality as code approach that we have been working in 2021 is based off this exchange, information exchange. 

    And also working with our customers, we realized that we’ve gotta go beyond infrastructure as well. Compliance and code, but two qualities a code where we help organizations define their government’s police, which is heterogenous and across organizations, sub organizations. But codify them and help them automate that process. 

    Alan: Exactly. So here’s an interesting thing from where I sit. Right? Sitting here running DevOps dot-com seven-eight years now. We can’t even have this discussion. We couldn’t have this discussion until we reached a certain level of maturity in the way we approach. Let’s forget compliance for the moment, but infrastructure as a code. 

    Prashanth: Yeah. 

    Alan: Right? Because you can’t start talking about compliance as code, and policy as code, and security as code until you got that infrastructure kind of down pat. Right? And so the fact that we are even having these discussions, right, and thinking about it, and implementing tools around it, you know, it was almost the proof on its face. Right? “Prima facie” as they say in law in school. Prima facie. That we are, we have matured, right, in the way we’re deploying our infrastructure, the way we’re automating infrastructure. So I’m calling infrastructure as code. Right? 

    Prashanth: Okay. 

    Alan: What do you think as we look ahead to 2022 and 2023, that continued maturity, what does it mean for policy as code? What’s next in other words? 

    Prashanth: I think a slight deviation from that is you said that is that you said about infrastructure expanded to DevOps methodology. Because I think that is the mindset shift that needed to happen for people to actually add up infrastructure as code, and then subsequently compliance and other paradigms, which would help them in automation. I think that is the foundation and we are seeing more and more companies seeing this as tables takes. 

    And again, they’re also – it has been a – there is a mindset shift that from where I see, it used to be a play for cost or optimization because of their bottom line. They wanted to reduce their development cost. They wanted to reduce the cost of having a breach. They wanted to reduce cost of finding a defect late in the cycle. But these days, I think is fight for spotlight because every – there is so much competition that is emerging, and there is no choice but to make your product available to your end consumer as soon as you can. 

    If you don’t do that, someone else is going to grab that opportunity for you. This makes it very, very important for organizations to take this learning that we talked about, which is a testimony that we are talking about compliance and security, but take the previous learning into their foundation. So that is what’s happening. Every new start-up that I talk about, I tell them in DevOps, these are something that they don’t even think as non-optional. Right? These are table stakes. 

    And from that point, they go on beyond, okay, I got my deployment automation. But hey, I have the security issue. I operate in a finance market. I operate in a banking sector. I operate in a hotel business. I operate in healthcare business. How can I make sure that I stay competitive? I make my data secure? This mindset of having faster time to market is making them add on these things very natural. And policy as code, whatever we are seeing, I think this is one of the common factors day one to stay competitive. 

    Alan: Got it. Excellent. All right. Prashanth, unfortunately we’re closer to 20 minutes now than we were to 15 that I told you we would do. Hey, we could continue this conversation though, but I think we’re in the right place. I think it’s something that resonates with the audience. For people wanting to get more information on Chef and Progress around this, where do they go? 

    Prashanth: Of course, we have a very vibrant community for Chef. So Chef community can be found on Slack. That is where us and other practitioners also hang out. And of course many of us are super active on LinkedIn as well. So these are the two places I think we can engage faster, and communities like this is probably the fastest to engage in Chef product, and engineering folks. 

    Alan: Okay. Hey, thanks for coming on TechStrong TV today. We’ll see you again soon. Best of luck to all the folks across Progress and Chef. 

    Prashanth: Thank you. Thanks for having me. 

    Alan: Okay. Bye-bye. All right. We’re gonna take a break. We’ll be right back.