staging-devopsy.kinsta.cloud

Tag: devops

  • The Risks of Shadow Code

    The Risks of Shadow Code

    As the economy struggles to recover after the last two years of the COVID-19 pandemic, we have all learned a thing or two about supply chains—and what happens when they break down. But many people do not realize that modern websites also have digital supply chains, third-party ones that can be compromised in myriad ways. And just like the disruption of the physical supply chain affects things like pricing, availability and inventory, digital supply chains found on today’s websites play a big role in critical areas like site performance, customer experience and overall analytics. As a result, businesses today need to be aware of how the digital supply chain can introduce significant risk, especially when third parties do not adhere to their own set of stringent standards around security and compliance.

    According to a recent study by Source Defense, organizations that collect and use sensitive data—such as health care, finance, travel and online retailers—need to strengthen their focus on third-party risk management. As a result of mandates like GDPR and PCS DSS, these companies are now bound by compliance requirements to ensure their client-side threats are avoided and/or mitigated. This effort means recognizing more than just how to protect private data—it means understanding the properties of malicious code known as “shadow code” on modern websites and how it generates risk from dynamic and unpredictable scripts. Companies dealing in data today need to be aware of the different ways shadow code can affect their security, as well as the productivity and integrity of their DevOps teams.

    Third-Party Scripts and Shadow Code

    Shadow code refers to code that is baked into an application without proper vetting by the website’s IT department. This malicious code thrives in the cloud landscape, primarily because it allows for ease of deployment through CI/CD automation.

    When a web page calls in a third-party script, it loads directly into the browser from a remote server, which means general security controls such as firewalls and network monitoring tools are bypassed. And if one of these scripts has been compromised by a bad actor, shadow code can be embedded within. Sometimes these scripts include open source software that hasn’t been tested well—or at all. Other times, the code may be pulled from another layer of the organization where malicious code is hiding.

    Shadow code presents an array of threat opportunities, including the ability to mount an attack through digital supply chain partners. When these compromised scripts are used to steal data, redirect web traffic,or any other malicious activity, a clear path is essentially created into thousands of different websites, in almost every industry that collects data or deals in digital transactions. When a third-party script with shadow code enters a system, it gains the ability to:

    • Record keystrokes
    • Redirect visitors to malicious websites
    • Monitor clicks and track website activity
    • Change content on websites, including images and text
    • Steal credentials, such as personal logins and social security numbers

    As we know, these digital activities can lead to big consequences, like data breaches, fraud, theft, compliance violations, loss of reputation and hefty fines. Although code reviews can provide some software quality assurance, the process is not effective against shadow code, mostly because these scripts are constantly altered by third-parties. And when the threat is underestimated and unattended, these malicious scripts have the potential to permeate every area of a company’s web property.

    Because the benefits of using these types of third-party scripts are considerable, it can be hard to find a modern enterprise or agency that does not rely on at least a few to run web applications. In fact, many enterprises and government agencies today are running third-party scripts on every page of their sites. Even though these organizations are technically not responsible for this harmful code, regulators can (and do) hold web property owners accountable for any digital maleficence on their sites.

    DevOps Teams and Shadow Code

    Websites can provide rich experiences to visitors largely because developers use client-side JavaScript to improve the look and feel of these digital properties—all without the need for ongoing maintenance. Today, DevOps professionals can access vast libraries of these free and low-cost scripts from many different sources, such as allied coder groups, open source organizations, social media companies, web analytics firms, content delivery networks and more.

    But the reality is, code libraries accessed by DevOps teams are not always secure or trustworthy. Considering these packages often contain code from fourth and fifth parties, DevOps folks face the unavoidable possibility of tainted code—hard to identify and dangerous to use. In fact, the Source Defense report revealed that one in four scripts represented fourth- or fifth-party code, on average. Because developers tend to focus on keeping their code updated and as capable as possible, they often pull from the dynamic library from their repository. If there is a CI/CD process happening, DevOps teams will pull their library from that point. This is where shadow code introduces new vulnerabilities for developers.

    Shadow code also jeopardizes the integrity of DevOps work. Most developers take pride in what they do and are not interested in creating unsecure or low-quality code—not purposefully, anyway. And given that speed, productivity and constant innovation are all business goals for DevOps teams, it’s important to recognize how problematic shadow code can be for those in the business of building secure and high-quality software.

  • Future Forward

    Future Forward

  • DevOps/Cloud-Native Live Boston: Get Certified, Network and Grow Your Career

    DevOps/Cloud-Native Live Boston: Get Certified, Network and Grow Your Career

    DevOps and cloud-native technologies are changing the application development landscape, accelerating the pace of innovation and transforming the way organizations develop, deploy and employ modern software. The DevOps/Cloud-Native Live! event is coming to Boston on May 25 to provide attendees with all the knowledge and tools they need to succeed in the world of DevOps and cloud-native computing.

    This in-person event will bring together DevOps luminaries and cloud-native experts to discuss some of the hottest topics in the industry today, share valuable insights and offer hands-on training to all attendees to help them future-proof their careers and stay ahead of the competition.

    DevOps/Cloud-Native Live! Boston features a stellar lineup of speakers, including:

    • Tracy Bannon, software architect and DevOps advisor at Mitre Corporation
    • Andi Mann, CTO at Qumu
    • Joshua Corman, former chief strategist, CISA COVID-19 task force and founder of I am the Cavalry
    • Elizabeth Lawler, founder and CEO at AppLand
    • David Owczarek, former SRE manager at Adobe Sign
    • Daniel (Dan) Kirsch, managing director and principal analyst at Techstrong Research

    At the conference, attendees will have the opportunity to meet these leaders and speakers, exchange ideas and information with like-minded peers, attend educational sessions and get certified by completing upskilling sessions. These upskilling sessions are designed to help both new and seasoned engineers hone their skills, adapt for future growth and improve operational efficiency.

    Joshua Mazgelis, cloud architect and senior sales engineer at Progress will be conducting a hands-on training session on “Cloud Agility with Chef.” In this session, attendees will learn how they can improve cloud security and compliance without sacrificing agility and how to use Chef software to detect, correct and automate remediation of security vulnerabilities across the infrastructure.

    Check out our interview with Joshua Mazgelis below for a sneak peek of what to expect from the “Cloud Agility with Chef” upskilling session.

    [videopress oyeKYTnR]

    The agenda for DevOps/Cloud-Native Live! Boston features a mix of topics, including technical sessions, lively discussions and case studies covering digital transformation, DevOps principles, Kubernetes, cloud-native tools, DevSecOps, API security, monitoring and observability, ITIL v4 and more.

    There will also be two amazing onsite giveaways:

    • Attendees will have a chance to win a pair of tickets to a Red Sox versus Yankees game (Terms and conditions apply).
    • Attendees will get a chance to snag free tickets to a pre-release private viewing of “Top Gun: Maverick” (First come, first served).

    By visiting the expo hall, attendees will also be able to interact with sponsors and receive valuable content. Breakfast, lunch and coffee will be offered to all attendees as well.

    To see the full agenda and to register, please visit the DevOps/Cloud-Native Live! Boston website.

  • Making DevOps Smoother

    Making DevOps Smoother

    Being a DevOps developer isn’t just about technical expertise necessary to build a product. It is also about learning the operations that facilitate the entire process. That means working with a fast-paced, high-performance, cross-functional team using Agile methodologies. But because of these sometimes-conflicting demands, it can sometimes get rocky.

    Here, we’ll offer six tips for DevOps developers to ensure a smoother development process.

    Set Measurable Goals

    While working toward a specific goal, precision is paramount. Defining the problem accurately leads to a faster solution. For instance, “Configure deployment to a new region” is too vague compared to “Configure the deployment of all components of service X for North America.” The more specific aim of the latter makes it easier for the parties involved to identity the problem, make a plan and resolve the issue quickly.

    Most DevOps developers use the acronym SMART while setting goals in a sprint.

    1. Specific: Define exactly what needs to be done.
    2. Measurable: Highlight the parameters and values necessary to indicate completion.
    3. Achievable: Define how the task will be accomplished and decide who will be responsible for doing it.
    4. Realistic: How realistic is the goal based on the above details?
    5. Timely: Set the date and time when the task has to be completed.

    While setting goals for a particular sprint, keep the above five points in mind to make sure that the tasks are precisely defined.

    Document Everything

    Proper documentation during the entire course of development is valuable to everyone. In many cases, DevOps developers join the project after it has started, and having them review documentation created by other developers is the easiest way for them to get up to speed. Not only that, but documentation also helps with debugging, troubleshooting and guiding the clients.

    Documentation of the process is often seen as boring and a waste of time. However, thanks to online documentation tools, logging information has become a lot simpler. Using a document template with good formatting makes things easier down the line.

    Communicate and Collaborate

    Essentially, the efficiency of a DevOps development team boils down to how well they communicate and collaborate within the team and with the external stakeholders. Gaps in communication will slow down and possibly derail the entire development process. This is especially important as more and more teams are going remote and popping into your coworker’s physical workspace to ask a quick question is no longer possible.

    In a remote working environment, communication can be slower. Sending a text, waiting for a reply, scheduling a call, etc., adds a lot of steps to the process as opposed to simply pointing at a screen and asking a question. Although there are a lot of visual collaboration tools and more integrations for video conferencing tools, it is still not the same.

    Therefore, it is important to set firm communication and collaboration rules and make sure expectations are set from the beginning so that team members and stakeholders know what to expect. One of the easiest ways to do so is by having specific tools for specific channels of communication. Typically, there are three types of communication tools that are necessary:

    • Team communications: Messaging apps like Slack and Microsoft Teams.
    • Stakeholder communication: Basecamp, Workzone or regular email.
    • Video conferencing: Can be used for internal and external communication. For example, Zoom, Google Meet, etc.

    Automate Repetitive Tasks

    If there are certain recurring tasks that happen at a local level, you can use Bash or PowerShell. Bash is older and used by a lot of IT and DevOps teams. PowerShell, developed by Microsoft in 2006, is newer and has replaced the command shell in Windows environments.

    Although both Bash and PowerShell are cross-platform, generally Bash is preferred by Linux and macOS users whereas PowerShell is preferred by Windows users. Ultimately, it comes down to personal preference. No matter whether you choose Bash, PowerShell or a newer automation tool, automation will save a lot of crucial development time and remove toil from a developer’s workload.

    Choose the Right Tech Stack

    Every team is different in terms of their requirements and the tools they prefer. “DevOps tools” is a term that covers everything from server orchestration tools, cloud platforms, code management and many other categories. In simple terms, DevOps tools are instruments that make it easier to write, test, host and deploy code. There are many DevOps tools that a development team can choose from. Here are three of them which are worth considering.

    1. Git: Git is a version control and distributed source code management. It makes it easier for developers to collaborate, experiment and merge code on the main branch.
    2. Cloud IDEs: Fully hosted cloud integrated development environments (IDEs) protect your progress in case your local system fails. GitHub Codespace, Cloud9 and Glitch are the most popular ones.
    3. Containers: Containers simplify the build, test, stage and deploy pipelines. They can either be locally hosted or fully hosted on the cloud. Containers help to identify and fix issues before they are deployed.

    While choosing your tech stack it is important to keep the user experience and user interface, usability, scalability, available integrations and pricing in mind. Your tools should fit into your process, not the other way around.

    Value DevOps Culture

    The work culture is essential for the cumulative success of the entire DevOps team. The way the team interacts with each other defines the way they work. When a team is provided with a sufficient amount of freedom to make its own decisions, it will come up with innovative ways to make the overall process more efficient. Overcoming the divide between “dev” and “ops” in its own way will empower the team to do its best work.

    With that being said, remember that a culture is something that develops over time organically, not forced upon people.

    Wrapping Up

    Developing software while collaborating with IT operations doesn’t have to be hectic or frustrating. By following these simple tips you can improve your entire team’s productivity. We hope that this article has provided you with some insights that will help you smooth out any development hurdles.

    Happy developing!

  • Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil

    Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil

    Balancing the speed of innovation with security is an age-old problem in software development. This is no different in modern DevOps. Development teams want a frictionless path to deploy new code but often struggle with access permissions that are linked to services. The CI/CD pipeline makes it easier for developers to quickly introduce new features and updates, in an agile way. As application changes move through the CI/CD pipeline, automation can allow changes to happen very quickly, without creating downtime or delays on the customer side.

    Permissions of CI/CD Servers

    When it comes to the permissions of CI/CD servers, DevOps often don’t want to deny access. After all, the wide access permissions are part of allowing the speed of innovation, and development teams are regularly—and often understandably—cautious about putting least-privilege or other access rules in place.

    But there are some security risks to consider. Any developer being granted admin permissions to deploy new code is open to vulnerabilities, weaknesses and misconfigurations. Cloud sprawl has created a lack of visibility into whether or not the infrastructure is properly set up and connected with logging tools. How does the development team know if things are getting properly patched?

    The balance is extremely sensitive. DevOps need the speed of change and the ability to innovate freely, but security teams can’t handle the growing risk. Something has to change that can allow security to shift left and get involved earlier in the CI/CD pipelines rather than getting in the way.

    Reducing the Risk Without Impacting Innovation

    Here are some suggestions for accelerating the speed of innovation while maintaining a healthy security posture:

    • Map threats and secure connections. Conduct a threat modeling exercise to map threats to the pipeline. Remember that every connection to the CI/CD pipeline is a potential point of compromise. Regularly patch and scan all services that connect to the pipeline and block the devices if they fail to meet security policy requirements.
    • Learn to love logs. When a security issue arises in production, developers, IT engineers and security engineers need to react quickly and efficiently to solve the problem. Logging is critical for enabling fast and coordinated responses. Waiting on manual sharing of sensitive data can slow down reaction times. But when every stakeholder can get the data they need from logs, access to information is no longer the weakest link in the security incident remediation process.
    • Tighten access control and enforce strong admin permissions. Be specific about who has access to which data. Clear and enforced separation of duties should ensure no one person or account can access more than necessary in the continuous software delivery pipeline. Improperly credentialed users or bad actors can’t establish control over the entire pipeline and mess with the code or processes. Moreover, they won’t easily be able to penetrate deeper into other corporate systems and data.
    • Leverage flags to manage risks. Developers often use feature flags (or feature toggles) to add new features to applications while mitigating the risk that those features will introduce performance or stability issues. Although most developers likely don’t think of feature flags as a security tool, they can be used for that purpose, too. New features are prime vectors for security vulnerabilities, especially if developers haven’t thoroughly tested them yet.

    Many security teams do not realize that just because their network is private, they’re still sharing pipelines with third parties, including anyone from maintenance to the team deploying your mobile app. By embracing these tools, developers can shift left, shoring up defenses early in the process, without adding a blocker to the pace of innovation coming from DevOps CI/CD pipelines.

  • Update Those Ops Tools, Too

    Update Those Ops Tools, Too

    We’re all pretty well settled on the idea that the rate of change in IT has been on the increase over time. From the advent of VMs to Agile to DevOps to containers, the movement has been faster—and the same is true for internal development.

    I’m going to approach this topic from three perspectives instead of my usual two. Kind of like breaking the fourth wall in cinema. We’ll discuss this movement just a bit from the perspectives of my two preferred bits, DevOps and DevOps. But for this blog, we’ll also mention DevOps—the infrastructure, tools and processes that enable the other two.

    For DevOps, languages—both updates to those currently in use and the addition of new ones—bring with them a nearly automatic update to tools used. Favorite libraries/modules, IDEs, build tools—these are all looked at and updated more frequently today than at any point in history, by my estimation. For teams that do not change languages or libraries much, source code analysis (SCA) scanning is increasingly helping to take a closer look at all those included tools and filter them based upon impact (normally security impact, but other impacts on occasion, too—like project activity and stability).

    For DevOps, the toolchain is still new enough that evolution is causing regular change, and that change is bringing with it new tools and utilities to solve the problems of this existing infrastructure. In fact, I’ve long thought the DevOps part needed a bit of a cooldown on the change and new tools/utilities front, personally.

    And finally, DevOps has gone a bit sideways in this regard. Every person—whether you call them ops, admin or DevOps—responsible for troubleshooting machines and apps has a collection of tools. But the divergence of platforms has created a divergence of tools. It is possible to work without a dedicated set of tools—and, indeed, many DevOps engineers do. Others have a folder. Meanwhile, there is another dedicated set of DevOps engineers that have a PCMCIA or USB full of useful tools that is always with them. Some have both. Of course, what tools are included in all of this varies widely also. It is an interesting artifact of our growth in IT that developers tend to share or borrow the best libraries/modules/APIs across an organization, but DevOps is more independent. As long as DevOps team members are getting the job done, no one is all that worried about which tools they used to troubleshoot. They do tend to share if asked, but with little physical evidence of what tools they used, it doesn’t come up often.

    So, what am I getting at? Look for ways to enable DevOps tool sharing on an ongoing (or at least regular) basis. An internal social media channel dedicated to the vendor your teams use to communicate, brown bags, a maintained rating system “Why I think fdisk rocks” type of thing, etc. The more power there is at the fingertips of every DevOps member you have, the better. Given our history, building an “approved” list is likely a bad idea, but having that central communication location that security can also peruse to look for red flags is not a bad idea. Of course, they are likely too busy, but worst case, such conversations can help in forensic analysis later. Not being cynical, just living IT in the 21st century.

    And keep kicking it. More and better tools will help keep all those sweet apps and servers clipping along, so there is really only upside here. Give your teams the tools and revel in your considerable uptime.

  • Jamstack Will Revolutionize How Websites Are Built

    Jamstack Will Revolutionize How Websites Are Built

    Today, every organization wants a website that loads quickly and looks sharp. The reasons go much deeper than cosmetic motivations, though—even a slight delay in loading can cause users to exit a page prematurely and site performance plays an important role in search engine rankings. Meanwhile, threats like ransomware and phishing are everywhere and are constantly evolving, requiring organizations to look for more ways to improve site security and protect user data from bad actors. Then, of course, there’s the need to quickly and easily scale websites to meet sudden spikes in demand. The need to adapt quickly has become especially apparent over the last two years as we have come to rely on the internet in new and profound ways compared to pre-pandemic times. Fortunately, a relatively new but popular approach to web development—Jamstack—is taking websites to a nearly infinite level of scalability and performance, serving up only what you need, when you need it. To understand the value that Jamstack brings today, it’s helpful to take a look at how we got here. 

    Throughout the history of the internet, web and database servers were the primary infrastructure for site hosting. When websites got more complicated, another layer, called the application tier, would take on more complex aspects of the site (like an API, for example). As traffic increased, web servers were scaled out to add capacity with the help of load balancers. Scaling in this manner wasn’t always easy or cost-effective, given how unpredictable consumer demand and spikes in traffic often are. Later, content delivery networks (CDNs) came into the picture, taking a load off web servers by pushing static content to the edge. But, for most traffic, the origin servers would still have to be ready to serve site visitors. In this approach, website development and management were often costly and difficult to scale, and sites faced constant security risks. 

    Enter Jamstack. With Jamstack, all site content sits on a CDN, ready to be served. Web pages are pre-rendered instead of being rendered in real-time (as was the case in pre-Jamstack days). As such, content is closer to the end user, pages load faster and sites can easily scale up or down to handle unexpected shifts in traffic.

    Jamstack represents an exciting and fundamental shift in how we have traditionally approached web development—one that is inclusive of the needs for performance, security, availability and scalability and at a much lower cost to the developer. It’s no surprise that Jamstack has taken the web development world by storm over the last couple of years; in 2020, the number of sites developed with Jamstack jumped 85% from the year prior. Here, I’ll share some basic tips for getting the most out of Jamstack.

    Adding Dynamic Features to Static Sites

    Jamstack starts with the idea of a static site—pre-building as much of a site as is practical—and incorporates dynamic elements to achieve fast websites with fewer attack vectors. The term, which was coined in 2015 as JAMstack, derives from: 

    • J = JavaScript, the website’s programming language 
    • A = APIs, which enable dynamic content on an otherwise static page
    • M = Markup, which is the HTML and CSS code that provides formatting instructions to the browser 

    By combining these three elements, Jamstack allows developers to quickly create and maintain websites that can be served efficiently to users. A static site renders well for mobile, web and video while relying on APIs for dynamic features. High page speed is achievable by pre-building as much of a site as possible and then using a CDN to deliver the page to users around the world. When a user visits a website, they see a pre-rendered page delivered by the CDN with no dedicated servers needed.

    Notably, the page’s static nature does not require the content to be static. Leveraging third-party APIs can enable dynamic content such as search, payment processing and real-time data. This modular approach allows for flexibility and avoids vendor lock-in—swapping out different APIs as technology changes and new tools become available is easy. The ability to integrate with serverless functions also lends itself to Jamstack sites becoming more dynamic.

    Without the need for web application servers and database servers, Jamstack pages scale well as visitors increase, improving both the experience of the visitor and the organization’s bottom line.

    In essence, a Jamstack site has no backend that needs to be managed by a developer. The static nature of the page means there is no link between the website and a database, which reduces the security attack surface. Since all site elements are delivered from the CDN or an API, potential attackers aren’t able to hack web application servers or database servers.

    When an organization creates a website with this approach, there are no servers to maintain and no staging environments to create, so there is less of a need for complex DevOps resources. Jamstack’s simplicity means there are fewer moving parts than in a traditional site and less room for error. Because of this decoupling between the frontend and backend, Jamstack sites are faster to launch and more reliable.

    Another advantage of the static setup is that reverting to an earlier version of a page is simple. This is possible through the concept of atomic deploys, where the entire site is updated at once, creating a new version. With Jamstack, developers have more freedom to experiment and avoid the tiring trial and error of traditional sites—if something does not render as intended, switching the entire site back to a previous version is painless. 

    Assembling a Jamstack Toolkit

    Jamstack’s tools, processes, and best practices are evolving rapidly, and an important part of diving in is remaining open to experimentation and tracking emerging developments. Getting started is simple since Jamstack integrates with existing workflows and many organizations have established relationships with vendors already in place for key technologies, speeding up the decision-making process. These technologies include:

    • CDN: To deliver pages from locations close to users—a requirement for achieving fast performance. 
    • Static site generator (SSG): To generate the site using raw data and templates—automating the process of coding pages and ensuring they are pre-built and ready for users.
    • Content management system (CMS): To act as a content repository. A CMS for a Jamstack website is described as “headless,” which means that content is stored outside of the codebase and delivered via APIs for seamless display across different devices.

    Expanding the Value of Jamstack

    We are still in the early years of Jamstack’s maturation, and not all deployments are equally effective. For example, some Jamstack platforms are hosted out of centralized data centers coupled with a CDN, which slows performance relative to delivering sites directly from the edge. Some Jamstack hosts also charge more to add developer seats, which discourages collaboration among large teams and can result in unpredictable pricing. 

    Regardless, Jamstack is one of the best technological solutions to come to developers in recent years and one which will surely influence the future of web development. Not only does it make websites faster, more secure, and easier to scale, but it builds on many of the tools developers already know and love—empowering them to achieve their maximum productivity.

  • DevSecOps: Realities of Policy Management

    DevSecOps: Realities of Policy Management

    Policy management is essential to scale cloud environments and is key to secure DevOps practices. It enables organizations to manage policies put in place that secure the cloud environment, ensure Kubernetes configurations are secure and enable the continuous monitoring of a company’s overall security posture. 

     As businesses migrate workloads across multi-cloud architectures to achieve the agility and scalability needed to keep up with the pace of digital transformation, the growing demands placed upon developers often leave a gap that exposes potential threats and risks in the configuration settings, making security an even greater focus in DevOps. In fact, IDC’s 2020 survey found that 67% of breaches in the cloud are caused by misconfigured applications or infrastructure, including some of the industry’s largest breaches like Marriott’s second breach.

     To add to this, the first State of Policy Management report by Nirmata and the creators of the CNCF project Kyverno revealed that nearly 50% of users in cloud-native environments have now adopted some type of policy management solution. This tipping point of mainstream adoption across production cloud-native environments is making it critically important for DevOps teams to look at their practices and simplify and operationalize policy management across their Kubernetes stack by eliminating vulnerabilities through built-in, curated policies, without the barrier of learning complex policy languages. But this widespread adoption also acknowledges that organizations are finally realizing the need to put attention, investment and innovation into addressing security and compliance gaps as they adopt Kubernetes through proper DevSecOps practices and tools so applications being built can empower businesses.

    To confidently build cloud applications in Kubernetes, DevSecOps teams need to accept these DevSecOps realities and apply policy management effectively. 

     Customization Creates Security Risks

    Kubernetes can be highly customized, but DevSecOps teams need visibility into what’s happening in each cluster as organizations scale to ensure application reliability and security. Exploits on containers—including malware installation, cryptomining, host access and privilege escalation—offer opportunities for more security vulnerabilities. They can exist in images, production-accessible container registries, failed builds and third-party admission controllers in Kubernetes clusters.

    To address these risks in applications running on Kubernetes, it’s important to protect your environment with three A’s: Authentication, authorization and admission. This should be done at the cluster layer which enables secure access to authenticated entities that are authorized to perform certain actions. One way to accomplish this is through policy management. In fact, according to the State of Policy Management report, the top use case for policy management is for Kubernetes admission control (31%). When a request is authorized, having a policy in place ensures the request goes through another set of filters. For example, an authorized request may be rejected by an admission controller due to quotas or due to other higher-priority requests. In addition to validation, admission webhooks can also mutate incoming requests as a way of processing request objects for use before reaching the Kubernetes API server. 

    Configuration Issues

    Container images, namespaces, runtime privileges, persistent storage and control plane, together with network policies that are not compatible with best practices, are a source of misconfiguration and risk exposures. It’s this potential for greater risk exposures that have led configuration management to be a key driver of policy management adoption. In the Nirmata State of Policy Management report, it ranked third in security tools that are adopted today and fourth for the organization’s plans for future adoption.

    There are several ways to define security policies to protect cloud environments. Policies can be used for auditing purposes, to reject pod creation or to mutate the pod and limit what it can do. By default, pods can receive traffic from any source and send traffic to any destination. Network policies allow you to limit the ingress and egress access for your pods. The network policy typically translates to firewall rules.

    Lack of Adequate Authorization 

    Cloud authentication allows authorized users to securely access information stored in the cloud with authentication provided through cloud-based services. In The State of Policy Management report, key findings revealed that more than 24% of respondents today are using tools like policy management to authenticate users accessing applications. With data theft one of the fastest-growing and most expensive cybercrimes, the ability to process information and have strong authorization measures needs to be part of DevSecOps best practices.  

    In Kubernetes environments, as a user request is authenticated, it goes through an authorization workflow that decides if the request should be granted. It evaluates the request attributes against all policies and allows or denies the request. The main authorization mechanism is role-based access control (RBAC). Each authenticated request has an HTTP verb like GET, POST or DELETE, and authenticated entities have a role that allows or denies the request. Other authorization mechanisms include attribute-based access control (ABAC), node authorization and webhook mode.

    As the trend of moving security further to the left in the application life cycle accelerates, developers are being required to take active responsibility for it, which creates a higher desire for automation. The rapid releases can expose applications to many vulnerabilities, raising the risk of a breach.  With DevSecOps, organizations can transform the development pipeline by shifting security and compliance to the left, enabling developers to check the code before every commit. In doing so, security and compliance vulnerabilities can be identified and fixed in development, saving the organization from high costs and negative publicity from potential breaches. 

    There’s no doubt that Kubernetes is complex and challenging to adopt. On top of this, the development landscape is flooded with tools and more demands are being placed on engineers.  These shifts are changing the traditional role of a developer, leaving a gap for organizations to address to get the most out of DevOps. But by taking a secure, continuous, iterative approach that also includes policy management, companies can reduce the risk and exposure of their cloud environments. The more mature an organization’s DevOps practices are, then generally, the stronger the security and compliance practices are—they grow in relation to each other. The most innovative companies accept policy management in DevSecOps as a necessity of development and adopt some level of policy management best practices. With the right implementation tools like policy management and security and compliance best practices, organizations can remain efficient in agile and DevOps while adhering to critical go-live deadlines—which can’t be missed in this fast-paced business environment. 

  • This is Not Just a Test: DevOps and the Need to Automate

    This is Not Just a Test: DevOps and the Need to Automate

    Creating software is as much about the process as it is about the product. In recent years, we’ve seen the speed of innovation reach new heights due to more efficient development and quality control. DevOps has further accelerated development by combining software and operations in unified, self-improving teams. With automation taking care of rote tasks, developers can now tackle more difficult issues, resulting in even greater software quality and faster development. The need for speed to market is vital; a month or two can make or break a product launch. Then again, if a product isn’t tested thoroughly in the rush to get to market, flaws can slip through and an organization’s revenue and reputation can take a serious hit. In the U.S., software failures in businesses’ operations systems cost a total of almost $1.6 trillion in 2019. The problem is that it can be a bottleneck and create major delays in the release cycle. In fact, A recent survey of 4,300 developers revealed that it is the top reason that releases are delayed.

    In the past, the waterfall approach was common. Tests usually took place after code was written; carried out by testers who had no interaction with the original developers. As a result, bugs that could have taken moments to correct during development required days or even weeks to fix afterward. Even worse, the complexity of the finished software and its many dependencies meant that fixing a localized bug could introduce additional problems that needed to be fixed after another round of testing, further delaying the release.

    But even in a modern DevOps environment, testers and developers are still speaking entirely different languages. By and large, testers do not code and software developers are not expert testers. The two teams typically converse through multiple logs, event viewers and other operating system tools. It creates a great deal of friction and slows down the process.

    Shift Left 

    DevOps represented a big improvement over waterfall methods but, even so, it’s far from a set-in-stone process. It, too, has evolved and right now, shift left testing has moved into the spotlight.

    In this approach, the guiding philosophy is to test early and often, beginning very early in the development cycle and continuously throughout every stage whenever there’s an opportunity. As a result, bugs are caught early when the relevant code is still fresh in the developers’ minds, so it’s easier to fix. In the end, businesses are able to release higher quality software much faster and more frequently.

    Environmental Tests

    When it comes to the DevOps process, it’s not always clear where and how to automate the process. The following looks at how that can be incorporated into DevOps based on four different environments in a continuous delivery (CD) pipeline.

    These environments include local development (usually a coder’s personal device), a continuous integration (CI) or development server, test servers for user interface (UI) testing and the production environment itself. Each has stages with requirements that must be met for code to advance.

    Whenever any new software features or capabilities are entertained, though, developers and the QA team should begin by answering the question, “How can this be tested?”

    Moving Through the Stages

    Once code is created, it must be able to be built without error, passing all unit tests and local verification.

    This stage is particularly important because the development environment echoes the requirements of production; if it works here it’ll likely also work for the customer.

    At this stage, running early regression and developer verification tests ensures the build is ready while providing feedback about the reliability of the environment. It’s useful to have individual test cases as part of more than one schedule. This enables developers to test minor parts of the software without undergoing regression tests of all product features. These tests should be automated and triggered as part of the same process.

    Developers should have the ability to perform basic tests on their own code. After all, the sooner a flaw is identified, the easier it is to eradicate. Just as testers are not experts in coding, neither are developers expert testers. To shift left and effectively integrate tests at all stages of the development life cycle, it must be automated. This will allow developers to test larger quantities of code earlier and more frequently.

    Once through this stage, the software can advance to the test environment.

    This is where a variety of product tests take place, including those for function, load and performance. Passing this stage entails completing all automated functional UI tests, verification of visual appearance, an inspection of server logs and performance evaluation.

    This is where most regression tests are conducted and automation is crucial for scheduled tests to be triggered.

    Next, the product moves into the production stage.

    Tests still occur in this stage to pinpoint any remaining bugs. Automated tests are then run against the production environment to closely mirror interactions with real end users. At this point, it’s highly unlikely there will be major issues but, if there are, running tests at earlier stages could very well be the culprit.

    Throughout the process, ideally, testers will use a visual, no-code tool to create these automated tests. In this way, testers are able to more rapidly and intuitively implement test automation without having to tap into programming resources. Additionally, the integrated documentation of the actions taken during automation will be interactively connected to visual documentation of the test results. The upshot is that testers and developers gain a shared language for both building test automation and troubleshooting the issues it identifies.

    This is Not Just a Test

    Effective, scalable tests are crucial to delivering the reliable, high-quality software that today’s businesses rely on for day-to-day operations. This is why DevOps and development teams need to integrate tests at all stages of software development. Shift left speeds up the creation of better quality software, which provides a significant market advantage. After all, it’s not just about software quality; it can show which companies are best prepared to meet market demands.

  • 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.