devopsy.kinsta.cloud

Category: IT as Code

  • MDR for DevSecOps: How Managed Security Can Help You Shift Left

    MDR for DevSecOps: How Managed Security Can Help You Shift Left

    What is managed detection and response (MDR)? Managed detection and response (MDR) is an outsourced service that helps organizations detect threats on endpoints, respond to them and carry out proactive threat hunting.

    MDR services typically include an endpoint detection and response (EDR) platform, which is deployed on company endpoints, and human security experts. MDR providers give their customers access to security analysts and engineers who can help with endpoint security, network security management, triage of alerts and responding to real security incidents (here’s some further reading and more background on managed detection and response platforms).

    Why is MDR Important?

    Traditional managed security services (MSS) offer basic monitoring and alerting that do not provide the context and guidance needed to identify, respond to and remediate real security incidents. It leaves organizations exposed to many threats that pass through these basic services.

    How MDR Helps Protect Organizations

    MDR provides a proactive, outcome-driven approach that goes beyond the scope of what MSS vendors can offer. Common MDR services include:

    • Continuous network and endpoint monitoring.
    • Security orchestration.
    • Threat hunting.
    • Integrated response actions like remote threat containment.
    • Advanced MDR services also offer extended detection across clouds such as AWS, GCP, Azure and common SaaS suites like Google Workspace and Office 365. Other providers can protect incident command systems (ICS) and supervisory control and data acquisition (SCADA) systems within operational technology (OT) environments.

    What is DevSecOps?

    DevSecOps is a software development methodology that unifies previously disparate development (Dev), security (Sec), and operations (Ops) teams. It aims to integrate security across all development life cycle phases, including design, development, testing, deployment and delivery. It involves using automation to integrate security across all phases.

    In the past, security tasks were performed at the end of the development pipeline by a separate security team. Next, the product was tested by a quality assurance (QA) team. This approach worked when developers released software updates only once or twice per year. However, once software development teams adopted Agile and DevOps pipelines to reduce the development time, security became a bottleneck.

    How DevSecOps Improves Security

    DevSecOps integrates security into Agile and DevOps pipelines. It ensures teams can address security issues during the early phases of the development cycle. As a result, teams can apply fixes when it is easier and faster to remediate before products are released to production.

    DevSecOps makes security a responsibility shared by all teams, including Dev, Sec and Ops. It is no longer the sole responsibility of one team that creates a security silo. Instead, it enables teams to automate secure software delivery, prioritizing security without slowing down the software development cycle.

    How Managed Detection and Response (MDR) Solutions Benefit DevSecOps

    DevOps has revolutionized application development. However, due to the high velocity of modern development methods, they can introduce security gaps and flaws.

    In addition to regular security breaches occurring across the DevOps pipeline, new and sophisticated attacks, most significantly supply chain attacks infect the development systems themselves or third-party software components. This results in mega-attacks that can compromise millions of devices before being detected.

    How can MDR help?

    MDR is a relatively new cybersecurity offering but is beginning to have a major impact on companies seeking better protection with lower operational overhead. There are many overalls between MDR and DevOps. To integrate cybersecurity into production and deployment pipelines, some organizations are turning to a DevSecOps approach and MDR can help.

    DevSecOps makes cybersecurity an integral part of the entire DevOps life cycle. As more organizations implement DevSecOps, they can supplement the knowledge and security best practices of in-house teams with the security expertise provided by MDR services.

    How MDR Keeps DevOps Ahead

    MDR keeps DevOps teams ahead of the latest threats by keeping developers up-to-date on emerging threats and vulnerabilities and providing advanced tools for continuous security monitoring and response in their development and deployment pipelines. A key benefit of MDR is that it provides access to experts who can take action to prevent attacks, not just provide recommendations.

    MDR becomes a supporting element that allows developers to write more secure code as well as better secure their DevOps environment. With the help of MDR technology and experts, it becomes easier to identify advanced threats that can bypass security controls before they impact the DevOps environment or the resulting software product.

    Considerations for Selecting an MDR Solution

    • There are several important considerations when choosing an MDR platform suitable for a DevOps environment:
    • Understanding of attack surfaces common in a DevSecOps environment, and the ability to monitor and control the relevant environments.
    • Measures are taken to eliminate false positives and prioritize alerts. DevOps teams operate at high velocity and do not have time to wade through irrelevant alerts.
    • Automated triage and response at all stages of the development lifecycle. In earlier stages, this should take the form of actionable recommendations for developers, and in later stages, full incident response for production environments.

    All of this is useful as you find the right way to shift your organization to a true DevSecOps process.

  • Tackling the Complexities of Multi-Cloud With a New IT Model

    Tackling the Complexities of Multi-Cloud With a New IT Model

    The pandemic put incredible pressure on organizations to modernize and accelerate digital transformation efforts, with many businesses rushing to embrace cloud strategies in response. According to this year’s Enterprise Cloud Index from Nutanix, multi-cloud—an IT operating model that combines multiple clouds, public or private—is the most commonly deployed IT environment and the only IT model on an upward adoption trajectory. In fact, nearly two-thirds (64%) of organizations plan to operate a multi-cloud environment within three years.

    But there are complexities and challenges of managing across cloud borders that organizations are still grappling with, and concerns about security, data integration and cost remain. Enterprises will need to find ways to leverage existing cloud investments and redefine best practices and what it means to have agility and resilience in IT.

    Current Challenges

    Businesses have traditionally been designed around managing costs, increasing efficiency and streamlining operations, but lean IT teams find themselves under new pressures to support the challenges we’re facing today. The pandemic forced organizations to prioritize implementations and view the public cloud as a quick solution for everything without proper due diligence at the expense of optimization. This approach lacked focus on strategic business outcomes, and ultimately led to increased complexity, higher costs and less flexibility. According to the study, 87% of respondents agreed that multi-cloud success requires simpler management across mixed-cloud infrastructures.

    Enterprises also continue to rank improving security as a top IT priority, yet managing security was among the top multi-cloud challenges cited. Additionally, the majority of respondents (80%) say that moving apps can be time-consuming and costly, and 77% agree that workload portability is a significant challenge. This underscores the need for uniform management and operations across different cloud environments to avoid costly and time-consuming efforts to move applications.

    “Cloud-Smart” approach to IT

    Current cloud thinking is that there’s a “best” cloud environment for each workload or application, but there is no one-size-fits-all approach to the cloud. Organizations will start to move away from blanket cloud-first approaches to IT, and instead, be more thoughtful about which workloads run where. It is no longer a foregone conclusion that taking every app or workflow to the cloud permanently is the best course of action. The adoption of this “cloud-smart” approach, leveraging the most appropriate cloud environment for each use case, is likely a primary driver behind the proliferation of multi-cloud.

    The use of IT infrastructure by organizations is becoming more strategic over time. Nearly three-quarters of IT professionals (72%) feel that the IT function in their businesses is seen as more strategic now than it was a year ago. While businesses are now viewing and using IT more strategically than ever before, the complexity of multi-cloud is creating challenges that are standing in the way of cloud success. Despite challenges, a strong case is made for why the future of IT is hybrid multi-cloud, a model that enables more operational consistency across clouds. In fact, 83% consider it ideal.

    Multi-Cloud Supports New Ways of Working

    The pandemic has changed how nearly all organizations operate, and the top reasons cited by businesses for changing their infrastructure and deployment models are improving remote work and collaboration. While an organizations’ remote workforces may fluctuate, they are here to stay for the foreseeable future and IT will need to be nimble to support a remote, hybrid workforce and keep people productive and connected regardless of location.

    Over half (61%) of organizations are focused on offering more flexible work setups because of the pandemic, and multi-cloud supports this new way of working. It offers the most agile IT environment for supporting this kind of flexibility by distributing data and allowing remote access to business applications from diverse geolocations for user proximity and business continuity, and enabling organizations to implement technology that helps retain and attract talent.

    Multi-cloud is here to stay—and is the only operating model that is expected to increase in the coming years. 2022 will bring about a shift towards hybrid multi-cloud deployment as organizations look to take advantage of what each cloud has to offer while still having the flexibility and freedom of choice around their applications and data. This would deliver on the flexibility and agility that most organizations seek to compete in today’s digital world while enabling enterprises to significantly simplify operations. Future-proofing cloud strategies is the key to building IT resilience.

  • The Future of Cloud Strategy: Multi-Cloud

    The Future of Cloud Strategy: Multi-Cloud

    As Gartner’s Milind Govekar recently said, “There is no business strategy without a cloud strategy.” But in 2021, some of the world’s biggest brands suffered disruptions in their services due to outages from their cloud service providers, including Google, Slack, Venmo, Disney+, Facebook/Meta, Tinder, iRobot, The Washington Post and Sony.

    While the outages do not negate the overall benefits of moving to the cloud in the first place, they do make IT leaders think twice about putting all their eggs in one cloud provider’s basket. In this article, we will be exploring the multi-cloud strategy, its advantages and how to prepare for your multi-cloud future.

    Let’s Be Clear About Cloud

    The adoption of a cloud strategy was evidenced in a 2021 O’Reilly survey in which 48% of participants reported a plan to migrate more than half their applications to the cloud while 20% planned to migrate all their applications to the cloud.

    Cloud migration is a multi-factored decision made by business leaders to migrate electronic assets from local servers to the cloud. Cloud storage is rapidly overrunning on-premises data warehouses because of its many positive business impacts including scalability, speed, collaboration, continuity, security and rapid ROI. Although it is simple to select one provider, we’re seeing more and more organizations opt for multiple providers to avoid the negative impacts of outages.

    Multi-Cloud Strategy: The Dominant Choice

    Cloud revenue continues to reach new heights. Gartner predicted cloud revenues globally will reach $474 billion in 2022. That number represents a significant increase from $313 billion in 2020. 

    The challenge among many IT leaders is continually mapping the use of the cloud in relation to their business goals. This alignment is critical to the success of overall objectives as cloud solutions need to match business requirements, whether related to security, compliance or other issues. 

    Cloud-based solutions are highly sought after by businesses and IT leaders. In the quest for the “perfect” solution, multi-cloud options are highly appealing. Benefits of a muti-cloud system include: 

    • Avoiding vendor/provider lock-in
    • Allowing for scaling as business grows
    • Increasing security to thwart attacks
    • Harnessing unique capabilities of different providers

    Multi-cloud and hybrid cloud are often used interchangeably, but they actually refer to slightly different approaches. 

    Hybrid, strictly speaking, is the use of cloud infrastructure in conjunction with bare metal (aka traditional) data centers. As such, it has been an approach favored by enterprises migrating to the cloud in phases.

    Multi-cloud, as the name suggests, involves the use of more than one cloud provider to provision IT. Many would argue it’s also the future of operating as a cloud-first entity.

    Fast-Tracking Digital Transformation

    Digital transformation can be a long haul, however, businesses adopting multi-cloud solutions are navigating the digital services path more quickly.

    Why does the cloud present itself as the best solution for businesses?

    • Rapid advancement of cloud solutions
    • Apps are becoming more readily suited for development and deployment
    • Skepticism toward the cloud is now waning; businesses are porting databases and mission-critical apps to the cloud
    • Cloud is key to delivering AI services, an area of increased growth

    Flexibility meets Functionality

    Flexibility is undoubtedly a major attraction in relation to cloud choices. However, making the correct decisions is imperative to meeting strategic business objectives. The cloud proves beneficial to leaders as, in combination with data engineering, they can procure a comprehensive view of relevant data.

    The first critical component to selecting the correct cloud solution is market research. The necessity of this step is two-fold. Yes, it takes time to conduct research, but in the end, diligence can end up saving both time and money.

    Of course, businesses and providers want their relationships to be symbiotic. App migration may go well and all proper dynamics function at the onset, but what happens when a switch needs to be made? It can prove to be both burdensome and costly. With this reason in mind, it’s important to continually weigh both short-term advantages and longer-term flexibility. 

    Another essential component when assessing options is ensuring seamless interoperability between systems. Simply defined, interoperability is the ability of computerized systems to connect and communicate with one another without regard to their manufacturer or industry. 

    In a modern economy, IT leaders are called on to be increasingly conscientious about cloud services to alleviate any issues with future data portability.

    Edge Computing on the Rise

    Edge computing is a subset of a distributed computing topology in which information processing is located close to or at the location where that information is produced or consumed.

    With the trend of edge computing on the rise, the lines between edge and cloud computing continue to become more obscure. Cloud vendors need to use an edge strategy, and some already employ their own specific suite of services aimed at making data processing seamless.

    Data processing and transition should not be an arduous task. This factor alone influences leaders when making decisions on their cloud journey. Digital maturity is a competitive advantage for which all businesses should strive. 

    Adapting to Multi-Cloud

    A more complex cloud environment can be challenging, but the task is manageable. By dedicating the time and resources necessary, businesses can adapt to muti-cloud or hybrid systems with considerable ease.

    Whether through necessity or design, a multi-cloud or hybrid system has numerous benefits in relation to compliance, security, efficiency, scale, and performance. The multi-cloud strategy is here to stay.

  • Wi-Fi 7 Chips Ahoy | Google ‘Gone Downhill Fast’ | Real-World ‘Severance’

    Wi-Fi 7 Chips Ahoy | Google ‘Gone Downhill Fast’ | Real-World ‘Severance’

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The first silicon for Wi-Fi 7, Google’s search quality “is” failing, and what Severance tells us about The Great Resignation. (more…)

  • What’s the Difference Between SLI, SLA and SLO?

    What’s the Difference Between SLI, SLA and SLO?

    If you’re just getting into site reliability engineering (SRE) or platform engineering, you’ve probably come across a bunch of new terminologies, like SLI, SLA and SLO. These benchmarks are commonly referenced in the day-to-day life of an SRE but may seem foreign to outsiders. So, what are the differences between these abbreviations?

    Well, one of the hallmarks of the SRE approach is to gauge performance and set targets for application metrics. These targets can be thought of as reliability thresholds. If a site’s latency reaches a certain point, for example, it may break the agreement the software provider has with its consumer.

    SREs create and monitor service-level performance benchmarks for all sorts of metrics, such as uptime, latency, error count, mean-time-to-recovery and throughput, among others. But not all these performance goals are part of public agreements. Companies usually take a more proactive approach to setting more internal targets to stay far away from breaking external agreements and user trust. It’s become a best practice to set these baselines to retain functional, reliable systems.

    As mentioned, the type of targets range from firm partner commitments to more internal goals. Below, we’ll attempt to define, in simple terms, the differences between service-level agreement (SLA), service-level objective (SLO) and service-level indicator (SLI). While these concepts share many similarities, it’s important to understand how they are applied in practice. Keep in mind that each company may have a nuanced understanding of these terms and may conceive and apply them differently.

    Service-Level Indicator (SLI)

    First off, service-level indicators (SLIs) refer to the actual metrics produced by software services. This is a direct measurement of a service’s behavior. These are the real numbers that indicate overall performances, such as error rate and latency over time.

    One example of SLI would be the number of successful requests out of total requests over a one-month period. Say an engineer used an application monitoring tool that ingests data from production logs. This data showed that out of one million requests made, ten requests failed. An SLI for availability would thus be 99.999% uptime.

    Service-Level Agreement (SLA)

    Second, most technologists are familiar with service-level agreements (SLAs). Even if you’re not, you’ve likely agreed to many throughout your history as a digital user. SLAs are like a pact between the software provider and the software user or client. These binding commitments often note availability expectations that must be upheld. SLAs may also include responsiveness to incidents and bugs. It depends on the contract, but if an SLA is broken, some kind of penalty may be incurred such as a refund or a service subscription credit.

    These days, the average business relies on many cloud-based SaaS, PaaS and IaaS. Just to initiate something as simple as an online payment might require hitting multiple remote servers. But if all these services just went offline whenever they felt like it, our digital operations would come to a grinding halt. SLAs are thus necessary for enterprise software contractual agreements to ensure both parties meet specific standards.

    Once an engineer tracks SLIs and has an idea of typical behavior, they can then set an SLA that makes sense. If we take the example above, an SRE may consider guaranteeing a lower threshold than what is being actively monitored. This would ensure that application performance, at its current pace, doesn’t break any legal or contractual obligations. In this scenario, perhaps the SLA mentions an availability objective: No more than 100 requests fail per one million requests made. This would essentially equate to 99.99% uptime.

    Service-Level Objective (SLO)

    Lastly, service-level objectives (SLOs) are similar to SLAs but explicitly refer to the performance or reliability targets. An SLA may refer to specific SLOs. Or SLOs may be tracked just for internal purposes. As Google described, “the availability SLO in the SLA is normally a looser objective than the internal availability SLO.”

    You don’t want the end users to be the first people clamoring about a 400%+ latency rise in your mobile web apps. Thus, SRE teams typically keep a close eye on performance to ensure they never even get close to breaking SLAs. Some do this by setting and monitoring internal baselines that are more ambitious than the SLA threshold.

    If we take our example above, if an SLA guarantees a service uptime of 99.99%, the business may set an internal target of 99.995%. In other words, for every one million requests, no more than 50 should fail. If software systems aren’t hitting these marks, it’s a sign that the company must reevaluate designs and search for bottlenecks. Or, perhaps engineering teams have goals to improve the average downtime for the next quarter—an internal objective could be set at a higher standard than the currently perceived performance.

    As the Google Cloud blog described, “every service should have an availability SLO—without it, your team and your stakeholders cannot make principled judgments.” It’s a good reminder to be modest in your reliability commitments, they added, as consumers will come to expect this level of performance. On the other hand, setting more ambitious internal performance targets has the benefit of delivering a better result than the agreement on paper, increasing a software service’s competitiveness.

    Real-World Performance Benchmarks

    Keep in mind that the above numbers are simply for demonstration purposes. One interesting resource for real-world figures is API.Expert, a service that queries popular APIs and posts weekly performance statistics. Since APIs are the heart of many UI-based platforms (and our digital economy at large), these benchmarks stand as a good indicator of average uptimes and latencies in the industry.

    For example, at the time of writing, API.Expert’s Enterprise APIs collection ranked Microsoft Office365 and Pivotal Tracker at the top, both with a 100.00% pass rate and a 220 ms and 248 ms latency, respectively. On the other end of the spectrum, Docusign is at 99.93% with an 877 ms latency and Box is at 99.99% with 414 ms latency.

    SLIs, SLAs and SLOs—Oh My!

    Although it may sound good to an unpracticed ear, an SLA of 99.99% still equates to 52 minutes and 36 seconds of downtime per year. That’s nearly an hour of downtime in which customers are left scratching their heads or, worse, searching for other options. For traumatic health care situations, a loss of connectivity could be a matter of life and death.

    Although creating SLAs and SLOs is important to gauge system health, the reality is that it can be challenging to track and enforce them. “These agreements—generally written by people who aren’t in the tech trenches themselves—often make promises that are difficult for teams to measure,” according to the Atlassian knowledge center.

    In summary, SLIs demonstrate the real behavior of software systems. These metrics inform the creation of SLAs, which must be met to ensure B2B agreements. These SLAs often reference particular service-level objectives (SLOs) that must be met, which usually give more breathing room around SLIs. Lastly, in a digital economy with accelerating digital expectations, it makes sense to monitor internal SLOs and improve baselines over time.

  • Quali Adds Control Plane to Platform to Manage IaC

    Quali Adds Control Plane to Platform to Manage IaC

    Quali has added a control plane to its Torque platform to give DevOps teams the ability to consistently provision and orchestrate infrastructure across a heterogeneous distributed computing environment.

    Amir Rosenberg, vice president of product for Quali, said the control plane allows DevOps team to centrally manage the provisioning of infrastructure via reusable blueprints accessed via a self-service portal, which individual developers can access. That approach eliminates a bottleneck that occurs when DevOps teams manually provision infrastructure on behalf of development teams, he said.

    The latest release of Torque also adds enhanced visibility and cost control capabilities such as the ability to set limits for maximum duration and number of concurrent environments and limits for the total cost of an environment. Also included are cost reporting tools for Kubernetes clusters and improved forecasting and resource consumption policies that can be applied to blueprints, sandboxes and spaces.

    Security enhancements include new customizable role-based access to blueprints, API Token Controls and integrations with secrets management platforms.

    Through its software-as-a-service (SaaS) platform, Quali makes it possible to access Torque via either a cloud account or a user interface that connects to a GitHub account where blueprints are stored. The goal is to enable DevOps teams to maintain some control over how infrastructure is provisioned without impeding developer productivity, said Rosenberg, noting at a time when more organizations than ever are launching multiple application development projects, there is more sensitivity concerning developer velocity than ever.

    It’s a fact that infrastructure misconfigurations happen because developers make mistakes. It’s not uncommon for a port to be left open, for example, which cybercriminals later exploit to exfiltrate data. Quali is offering a DevOps platform that makes it possible to centrally apply policies that act as guardrails to prevent developers from making provisioning mistakes. An alternative to scripts created using tools such as Terraform, the blueprints can deploy complete application environments automatically. That approach also provides more visibility into how resources are being consumed.

    Every minute a developer spends managing infrastructure theoretically is one less minute they could be spending writing code. As application environments become more complex, Rosenberg noted it’s becoming that much more challenging for developers to cope with managing infrastructure as code. The issue is that DevOps teams who could provision infrastructure for developers are being overwhelmed by the number of projects they need to manage. As a result, DevOps teams are becoming bottlenecks. Naturally, that only encourages more developers to provision infrastructure on their own, which, Rosenberg noted, leads to more mistakes being made.

    It’s not clear when or even whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t rely on developers as much, but most seem to agree that developers have far better things to do with their time.

  • 15 DevSecOps Best Practices

    15 DevSecOps Best Practices

    DevOps is all about speed, agility and collaboration. But when it comes to security, DevOps teams often face unique challenges. From securing the application development process to protecting production environments, DevOps and DevSecOps teams need to be aware of a variety of potential security risks.

    To help you stay ahead of the curve, we’ve compiled a list of 15 DevOps security best practices and challenges.

    1. Secure your application development process

    The first step to securing your DevOps pipeline is to ensure that your application development process is secure. This means ensuring that only authorized developers have access to your code repositories and that all code changes are reviewed and approved by a qualified reviewer before being merged into the main branch. It also helps to have developers that you trust to do the job properly and to observe cybersecurity best practices throughout. Consulting places like rightpeoplegroup.com makes finding these kinds of professionals much more straightforward. 

    2. Protect your production environment

    Your production environment is where your application will ultimately be deployed and used by your customers. As such, it’s important to ensure that this environment is as secure as possible.

    One way to do this is to segment your production environment into separate tiers, each with its own level of access and security controls. This way, even if one tier is compromised, the others will remain protected.

    3. Implement least-privilege principles

    In general, it’s best to follow the principle of least privilege when it comes to granting access to your DevOps resources. This means giving users only the permissions they need to perform their job and no more. The reason this is so important to follow is that your employees constitute your biggest cybersecurity threat. This is not always for nefarious reasons, but often simply because they do not have the knowledge or understanding to keep your business digitally secure at all times.

    4. Use role-based access control (RBAC)

    Role-based access control (RBAC) is a type of access control that can be used to restrict access to DevOps resources based on the roles of users. For example, you could create a ‘developer’ role that has access to your code repositories and a ‘tester’ role that has access to your staging environment. By using RBAC, you can help limit the damage that can be caused by an insider threat.

    5. Encrypt sensitive data

    Any data that could potentially be used to identify or harm an individual should be encrypted, both at rest and in transit. This includes data such as social security numbers, credit card numbers and health information.

    One way to encrypt data is to use pretty good privacy (PGP) encryption. PGP uses a combination of public key and symmetric key cryptography to protect your data.

    6. Use two-factor authentication

    Two-factor authentication (2FA) is an additional layer of security that can be used to protect access to DevOps resources. With 2FA, a user is required to provide two pieces of evidence to verify their identity. The first piece is something they know, such as a password, and the second piece is something they have, such as a mobile phone.

    Implementing 2FA can help to prevent unauthorized access to resources and systems, even if a user’s password is compromised.

    7. Use secrets management tools

    A secret is any piece of sensitive information that should be kept confidential, such as a password or an API key. Secrets management is the process of securely storing and managing secrets.

    There are a number of secrets management tools available, such as Hashicorp’s Vault and AWS Secrets Manager. These tools can help you to centrally manage secrets and provide access control and auditing capabilities.

    8. Train your employees in security awareness

    One of the best ways to improve DevOps security is to train your employees in security awareness. This can help them to understand the importance of security and to identify and mitigate risks.

    There are a number of different security awareness training programs available, such as the SANS Security Awareness Program. Alternatively, you could create your own program tailored to the specific needs of your organization.

    9. Use a web application firewall (WAF)

    A web application firewall (WAF) is a type of firewall that can be used to protect web applications from attack. WAFs work by inspecting incoming traffic and blocking requests that contain malicious payloads.

    There are a number of different WAFs available, both open source and commercial. Some examples of WAFs include mod_security for Apache, NGINX Plus and F5’s BIG-IP ASM.

    10. Perform regular security audits

    Regular security audits are an important part of DevOps security. They can help you to identify weaknesses in your system and ensure that your security controls are effective.

    There are a number of different types of security audits, such as penetration testing and code reviews. It’s important to choose the right type of audit for your needs. If you are unsure, you can consult with a security expert.

    11. Use intrusion detection and prevention systems (IDPS)

    Intrusion detection and prevention systems (IDPS) are designed to detect and block malicious activity. IDPSes can be used to protect both physical and virtual resources.

    There are a number of different IDPSes available, both open source and commercial. Some examples of IDPSes include Snort, Suricata and Bro. They are often deployed as part of a security information and event management (SIEM) system.

    12. Implement a disaster recovery plan

    A disaster recovery plan (DRP) is a document that outlines the steps that should be taken in the event of a disaster, a breach or other security incident. The DRP should contain information such as contact details for key personnel and procedures for restoring systems.

    A DRP can help to minimize the impact of a disaster and ensure that your organization is able to recover in a timely manner.

    13. Use logging and monitoring tools

    Logging and monitoring tools can be used to collect data about the activity on your system. This data can be used to detect and investigate security incidents.

    There are a number of different logging and monitoring tools available, both open source and commercial. Some examples of logging and monitoring tools include Splunk, ELK Stack and Nagios.

    14. Conduct regular penetration tests

    Penetration testing (or pentesting) is a type of security test that simulates an attack on your system. The goal of pentesting is to identify vulnerabilities that could be exploited by an attacker.

    Penetration tests can be conducted internally or externally. External penetration tests are often performed by third-party security firms. Internal penetration tests can be conducted by your own staff or by using a tool such as Metasploit.

    15. Use access control lists

    Access control lists (ACLs) are a type of security measure that can be used to restrict access to DevOps resources. ACLs work by defining a set of rules that determine who is allowed to access what.

    ACLs can be used to implement a least-privilege policy and can help to prevent unauthorized access to sensitive data.

    Conclusion

    There are plenty of threats when it comes to DevOps and DevSecOps and, equally, a wide range of best practices that can be used to improve DevSecOps. By implementing these best practices, you can help to protect your system from attack.

  • Russian Dev Exodus | Puppet IPO FAIL | Intel 18A Ahead of Sched.

    Russian Dev Exodus | Puppet IPO FAIL | Intel 18A Ahead of Sched.

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: More than 100,000 tech workers leave Russia, Perforce buys Puppet, and Intel moves faster than planned. (more…)

  • The Argo Project: Making GitOps Practical

    The Argo Project: Making GitOps Practical

    If you’re a DevOps engineer, chances are you have at least heard the name “Argo,” seen the friendly squid logo, and wondered: What the heck is this tool everyone is talking about? 

    In a nutshell, Argo is a popular open source tool that is making GitOps practical for anyone who uses Kubernetes. But it’s much more than that because, by enabling GitOps, Argo will also make Kubernetes environments more robust, secure and reliable than ever before. 

    Let’s find out why the combination of Argo, GitOps and good DevOps engineers is a recipe for production panacea.

    What is GitOps and Will it Replace DevOps?

    GitOps is a new(er) process and paradigm used by development teams to manage infrastructure and deploy applications. The “Git” in GitOps refers to the popular open source version control system. GitOps uses Git as a single source of information for declarative configuration. Based on this declarative configuration, it works its magic.

    GitOps automatically manages the configuration and deployment of infrastructure using Git pull requests. When development teams make a change to Git configuration, a GitOps agent deployed in the environment automatically reconciles the changes with the live state. Every change to the live environment is captured in the Git repository, so teams have unprecedented visibility and auditability over system changes. Most importantly, it is trivial to roll back to a previous working version in case of fires in production.

    GitOps builds on the developer experience, enabling teams to manage their infrastructure using the same tools and processes they use to develop software, extending those tools to the realm of software deployment and infrastructure management.

    While some have touted GitOps as “DevOps 2.0”, many experts disagree, saying that GitOps is not a better version of DevOps, nor is it something that will replace DevOps altogether. GitOps is a technical practice that can be highly beneficial to DevOps teams. The DevOps engineer will not, as some fear, be replaced by a Git-triggered robot. But GitOps will make her and the developers she supports happier and more productive.

    What is the Argo Project?

    Argo is an open source project hosted by the Cloud Native Computing Foundation (CNCF) for building and managing continuous delivery workflows in Kubernetes, GitOps style. The unique aspect of Argo is that it is Kubernetes-native—designed from the ground up for a modern containerized environment.

    The Argo project consists of four main sub-projects:

    • Argo CD—A GitOps continuous delivery engine with a powerful GUI and CLI.
    • Argo Workflows—A workflow engine that supports workflows and directed acyclic graphs (DAGs) in which each process stage is a container.
    • Argo Rollouts—An advanced Kubernetes deployment engine that supports progressive delivery strategies like canary and blue/green deployments, which are difficult to implement in plain Kubernetes.
    • Argo Events—A Kubernetes event-based dependency management system, which can be used to trigger automated workflows in CI/CD pipelines.

    Requirements for Kubernetes in Production

    Kubernetes is an orchestration platform that can help deploy, scale, and manage containerized applications. It can manage containers and the underlying infrastructure—scheduling containers and managing their workloads. This capability integrates software development and platform management to improve application management and portability. 

    Kubernetes in production can offer many advantages. For example, it makes it possible to release frequent changes to a high-availability application while keeping them online and enables you to move applications from one cluster to another. However, you need to configure Kubernetes correctly to realize its potential.

    Configuring Kubernetes for production involves implementing requirements according to each use case. As a result, what constitutes “production ready” in one Kubernetes project may vary greatly between different use cases. However, there are still minimum requirements that should be applied to most use cases. Here are key requirements for Kubernetes in production:

    • Security—When securing Kubernetes for production, you need to minimize the attack surface. This means locking down the Kubernetes control plane, applications, and their associated data. You need to keep secrets secured, harden nodes, use role-based access control (RBAC), and keep your Kubernetes version up-to-date with the latest security updates.
    • Portability and scalability—You can maximize cluster performance by maintaining portability and scalability. There are many Kubernetes capabilities that can help you achieve this goal, including self-healing nodes and auto scaling the infrastructure.
    • Deployment velocity—Kubernetes makes infrastructure and applications management faster by automating related processes. You can use Kubernetes’ automated features with GitOps to increase deployment velocity across your CI/CD pipelines.
    • Disaster recovery—You can significantly minimize your mean time to recovery (MTTR) by using Kubernetes and GitOps together. GitOps can help you reduce MTTR to minutes and quickly and easily recreate your container infrastructure in case of a complete cluster meltdown. 
    • Persistence—To support stateful production applications you will need to configure Kubernetes persistent volumes, provision storage devices with multiple storage tiers, and ensure they are efficiently utilized.
    • Observability—Observability enables you to gain a high-level view into running services, helping you make informed decisions before deployment to mitigate risk. GitOps can help you continuously monitor Kubernetes deployments, ensuring you can act immediately when issues occur.

    Benefits of Argo Tools for Production Environments

    Argo CD

    Argo CD is a continuous delivery (CD) tool native to Kubernetes. While most CD tools only support push-based deployment, Argo CD works in pull mode, retrieving updated code from a Git repository and deploying it directly to Kubernetes resources. This allows developers to manage infrastructure configuration and application updates in one system.

    Argo CD key features include:

    • Automatically synchronizing application state in a Kubernetes cluster with the current version of declarative configuration in a Git repository (==GitOps).
    • Ability to visualize deployment issues and detect and fix misconfigurations.
    • Convenient web-based GUI and CLI.
    • Role-Based Access Control (RBAC) and single sign-on (SSO), including login via GitHub, LinkedIn, Microsoft, etc.
    • Support for webhooks triggering actions in GitLab, GitHub, and BitBucket.

    How does Argo CD make Kubernetes production ready?

    GitOps can help you achieve a true GitOps workflows in Kubernetes, which provides the following benefits in production environments:

    • Minimize failed deployments and rapidly recover from downtime—Argo CD lets you instantly revert and rollback easily if anything goes wrong in production, reducing recovery time to seconds. 
    • Built-in auditing history—Argo CD ensures that every change to a Kubernetes cluster ia audited in the form of a Git configuration change log. This provides a complete audit trail of who changed what in the cluster, enabling consistent operations and supporting compliance requirements. 
    • Greater visibility on the lifecycle of developed features—Argo CD provides traceability from every change to infrastructure or applications directly to the code commit that caused those changes.
    • Improved security—Argo CD provides strong security guarantees, leveraging strong cryptography to manage changes and verify authorship, and creating a complete separation between CI environments and production systems, eliminating many types of supply chain attacks.

    Argo Rollouts

    Argo Rollouts is a set of Kubernetes controllers and CRDs that provides advanced deployment features such as blue/green and canary deployments, experiments, and progressive delivery in Kubernetes environments. It can integrate with input controllers and service meshes to incrementally transition traffic to new versions during updates. 

    A key capability of Argo Rollouts is that it can query and interpret metrics from many sources to validate that a deployment works properly and perform automatic upgrades or rollbacks.

    How do Argo Rollouts make Kubernetes production ready?

    By default, Kubernetes provides the Deployment object which updates applications using the “rolling update” strategy. In large production environments, rolling updates are considered too risky because there is no control over rollout speed and no way to automatically roll back in case of failure.

    Another limitation is that out of the box, Kubernetes deployments cannot query external metrics, such as real user measurements of performance or engagement, to determine the success of a deployment. 

    Argo Rollouts can address all these challenges and enable full progressive delivery in a Kubernetes environment, without requiring complex configuration.

    Argo Workflows

    Argo Workflows is an open source container-native workflow engine for orchestrating parallel tasks on Kubernetes. Argo workflows are implemented as Kubernetes Custom Resource Definitions (CRDs).

    Key features of Argo Workflows include:

    • Defining workflows where each step in the workflow is a container.
    • Modeling multi-step workflows as sets of actions or DAGs to capture dependencies.
    • Running CI/CD pipelines natively on Kubernetes without configuring complex software development products.

    How do Argo Workflows make Kubernetes production ready?

    Argo Workflows lets you automate production workflows in any Kubernetes environment, whether on-premises, hybrid cloud, or multi-cloud. It eliminates manual processes and ensures automation is represented as declarative configuration, making it consistent, repeatable, easy to rollback, and easy to troubleshoot.

    Argo Events

    Argo Events is a Kubernetes event-based dependency manager that defines multiple dependencies for different event sources (e.g. webhook, S3, schedule, stream, etc.) and Kubernetes objects after event dependencies are successfully resolved. Help the trigger.

    Argo events by themselves are not very useful. To deliver value, you need to integrate with a system that can execute workflow steps. So you can use Argo workflows to set Argo events. This helps orchestrate parallel Kubernetes jobs.

    How do Argo Events make Kubernetes production-ready?

    Argo Events provides several capabilities that enable dependency management in production Kubernetes environment:

    • Manage dependencies for various event sources.
    • Ability to customize business-level constraint logic to resolve event dependencies.
    • Manage everything from simple linear real-time dependencies to complex multi-source batch job dependencies.
    • Compliance with the CloudEvents standard.
    • Ability to manage event sources at runtime.

    Conclusion

    In this article, I covered the basics of GitOps and the Argo project and showed how each of the Argo project’s key modules can help make Kubernetes production-ready with minimal effort from developers and DevOps engineers. The magic of Argo is its simplicity and the way it fits seamlessly into existing Kubernetes workflows. I hope this will encourage you to try it out and see if it can help with your organization’s production issues.

  • Survey Shows Shift to SRE Principles to Automate IT Management

    Survey Shows Shift to SRE Principles to Automate IT Management

    A global survey of 1,500 IT decision-makers conducted by F5 found that, on average, organizations are managing more than 200 applications deployed across an extended enterprise as well as more than 20 different security and delivery technologies.

    Lori MacVittie, principal technical evangelist in the Office of the CTO for F5, said that level of complexity makes it apparent that IT teams will need to embrace higher levels of automation to manage the IT environments that are now at the core of a wide range of digital business transformation initiatives. The survey revealed that more than three-quarters of respondents (77%) were embracing site reliability engineering (SRE) principles to automate the management of IT.

    A full 95% of respondents also planned to mine operational data for insights they could use to improve the customer experience and drive business growth. However, 98% of respondents also said they are currently unable to extract those needed insights from their existing systems. A total of 90% said they planned to implement some form of artificial intelligence (AI) to achieve that goal. More than two-thirds of respondents said their organizations realized that creating superior digital interactions for customers will require modernizing business processes and back-office functions.

    As part of those efforts, the survey suggested that application workloads are being shifted across highly distributed computing environments. In addition to the 84% of respondents that are planning to move workloads to the edge, the survey found two-thirds of organizations (67%) are currently or planning to repatriate applications from the cloud to a data center environment in the next 12 months. A total of 93% of respondents reported using some type of as-a-service offering delivered via the cloud today.

    Naturally, securing that many platforms also represents a major challenge. However, despite inherent risks, more than three-quarters (76%) of respondents said, given the choice, they’d turn off security measures to improve performance. That lack of willingness to sacrifice performance suggests that attitudes to security may not have changed much despite all the breaches that now regularly occur, said MacVittie.

    It’s not clear to what degree managing enterprise IT environments has become untenable; however, it’s clear that legacy manual processes will need to become automated. Organizations can’t afford to keep hiring IT staff to manage IT platforms that span everything from the network edge to public clouds. In fact, the survey makes clear that DevOps practices—in the form of the SRE principles first defined by Google—are gaining traction. That doesn’t necessarily mean everyone managing IT is becoming an SRE or an engineer, but it does suggest that automation frameworks are being more widely used.

    It may be a while before those automation frameworks are ubiquitous. However, one way or another, many of the tasks that have historically conspired to make working in IT tedious are going to disappear. The issue, of course, is to not wind up with islands of disconnected automation that introduce more complexity.