devopsy.kinsta.cloud

Category: DevOps and Open Technologies

Editorial Calendar for February 2016

GitHub Previews Free CI/CD Migration Tool Due in 2023

At its GitHub Universe event, GitHub today unveiled a bevy of updates to its cloud service, including a forthcoming set of migration tools. The tools will automate migrations from legacy continuous integration/continuous delivery (CI/CD) platform to GitHub Actions.

GitHub Actions Importer is already being used by a small group of enterprise IT organizations to migrate workflows and template the GitHub CI/CD platform.

Damian Brady, senior manager for developer advocacy at GitHub, told conference attendees that these free tools will become more broadly available in 2023. GitHub Actions Importer will be distributed as a Docker container that manifests itself as an extension of the GitHub command line interface (CLI).

One of the biggest challenges the company has faced in driving adoption of its platforms is that many DevOps teams don’t want to rebuild the templates and workflows they are already using on their existing CI/CD platform, he noted.

Other GitHub Actions extensions include native integration with software development tools for building internet-of-things (IoT) applications and support for personal access tokens (PATs) that enable more granular control over permissions and repository access.

Other security capabilities include expanded access to audit log events in the enterprise edition of GitHub, an ability for maintainers of open source repositories to privately share vulnerability reports and support for Ruby as one of the programming languages now supported by a CodeQL tool for discovering vulnerabilities.

Additional extensions to existing services for developers also were previewed, including an ability to interact with the GitHub Copilot tool for automating code writing using voice commands. Dubbed “Hey, GitHub!” the tool is available as an experiment being advanced by the GitHub Next research team.

Finally, the company previewed enhancements to code search-and-view capabilities in the Codespaces tool that will now be made available for free for up to 60 hours per month to developers.

GitHub claims its CI/CD platform is now being used to process 10 million builds a day, most of which are employing code accessed via its repository. It’s not clear how that compares to other CI/CD platforms, but it’s apparent the GitHub Actions CI/CD platform has gained a significant amount of traction as GitHub continues to make a case for creating tighter integrations between its repository and CI/CD platform. GitHub is also clearly signaling it will spend a lot more time wooing organizations that already have a legacy CI/CD platform installed.

In the meantime, the next era of DevOps has arrived as workloads become both more complex to build and deploy across highly distributed computing environments. Many of the CI/CD platforms that organizations deployed are now straining under the weight of multiple customizations and extensions that have been made over the years. Each DevOps teams will need to decide whether maintaining those platforms makes the most technical and economic sense or if they should migrate to a more modern platform.

Regardless of what they decide, one thing that is certain is that DevOps teams won’t be getting larger, so the need to invest in higher levels of automation has become pressing.

November 9, 2022
VMware Extends Equinix Alliance to Drive Managed Hosting Service

VMware today announced it has extended its alliance with Equinix to launch a managed distributed cloud service that runs instances of its cloud computing platform in hosted IT environments.

Announced at the VMware Explore 2022 Europe conference, the VMware Cloud on Equinix Metal service takes advantage of more than 240 Equinix data centers in 71 major metro areas around the world to deploy instances of the VMware Cloud platform running atop the company’s virtual machine software.

Narayan Bharadwaj, vice president of cloud solutions at VMware, said this VMware service extends the scope and reach of the company’s multi-cloud computing strategy beyond the scope of the major hyperscalers and traditional on-premises IT environments.

The goal is to provide a managed IT environment that provides an alternative for deploying latency-sensitive applications closer to the network edge where data can be processed and analyzed in near-real-time, he noted. In addition, Equinix’s hosted IT environment also makes it possible for IT teams to more easily comply with requirements in highly regulated industries.

It’s not clear what percentage of applications today are running in managed hosted environments versus a public cloud or local data center. But as more organizations decide not to operate data centers themselves, many of them are discovering managed hosting services are preferable to the cloud for reasons spanning everything from application performance and cost and security to compliance.

In some cases, organizations are determining that certain classes of longer-running applications initially deployed in the cloud are actually less expensive to run in an on-premises IT environment, noted Bharadwaj. A managed hosting option often provides the flexibility benefits of the cloud at a lower cost for those applications, he added.

As cloud computing evolves, it’s become apparent that IT is becoming more distributed than ever. Many organizations are finding they now have a mix of applications running on public clouds, in co-location facilities and traditional on-premises IT environments. The challenge is that with each new platform employed to run applications, the total cost of managing IT increases. Regardless of any potential infrastructure cost savings, each platform typically requires a set of dedicated specialists to master the frameworks need to manage it. In fact, the single biggest IT expense remains the cost of labor. VMware is making a case for a familiar IT framework that can be deployed anywhere to rein in those costs.

DevOps, of course, was created to provide a new approach to automating the management of IT at scale. However, DevOps continues to be employed unevenly, largely because there are not enough IT professionals with the programming skills required to successfully manage IT-as-code. Managed services are gaining traction because, in most cases, they shift the responsibility for managing DevOps workflows onto a vendor such as VMware.

It remains to be seen just how automated the management of IT will become in the months and years ahead. However, it’s apparent that, in the era of the cloud, more organizations are opting to rely on third parties to manage infrastructure so they can devote more resources to building and deploying applications.

November 8, 2022
Snowflake Makes Case for Building and Deploying Apps on Platform

During a Snowday 2022 event, Snowflake this week moved to make it simpler to build applications on top of its cloud platform for managing data in addition to enhancing the overall security of the platform.

The company has made generally available Snowpark, a framework for building Java, Scala, SQL or Python applications. Snowflake also committed to making generally available in early 2023 an open source Streamlit framework for building Python applications that Snowflake acquired earlier this year.

Snowflake also revealed it is adding observability tools to the platform to make it easier to build, test, debug, deploy and monitor data pipelines, including alerting tools (private preview), logging capabilities (private preview), event tracing (private preview), task graphs and history (public preview).

Torsten Grabs, director of product management for Snowflake, said those capabilities will make it easier to alert DevOps teams to issues that might arise with applications deployed on the Snowflake platform.

At the same time, Snowflake is also making it simpler to build data pipelines by making a Serverless Tasks capability generally available. In addition, the company is previewing a Schema Inference engine that makes it simpler to ingest data and a Dynamic Tables capability to declaratively manage data pipelines.

Other capabilities being added to the platform include a public preview of a Query Acceleration Service to make additional compute resources available on demand. Snowflake has also improved query efficiency with join elimination in addition to providing search optimizations.

There are also now cost optimization tools that enable IT teams to run a cost-benefit analysis of Snowflake services in addition to tools that make it easier to replicate data across multiple cloud computing environments running the Snowflake platform.

IT teams can now also replicate Streams and Tasks via a capability in public preview that enables data pipelines to seamlessly work on secondary Snowflake accounts and configure failovers using a graphical tool that is available in private beta.

Finally, Snowflake has also enhanced its cross-cloud Snowgrid Capability to make it easier to share both public and private listings of data in addition to applying tags to and searching masked data.

The latest editions to the Snowflake platform come at a time when more organizations are starting to adopt DataOps best practices to manage data. Snowflake is now making a case for building and deploying applications on top of a platform that automates the management of the data pipelines used by applications to access data.

It’s not clear to what degree the Snowflake platform will be employed to host applications, but the company is clearly betting the volume of data residing in its cloud platform will attract a wide range of application developers that, in turn, will need to be supported by DevOps teams.

Of course, Snowflake is not the only provider of a data warehouse or data lake that has similar ambitions. Regardless of platform, however, the one thing that is clear is that a convergence of DevOps and DataOps workflows is now underway as IT organizations look to streamline the management of the massive amounts of data that now reside in the cloud.

November 8, 2022
Cisco Adds Open Source Tool to Validate Serverless Functions

Cisco has launched an open source project, dubbed FunctionClarity, that makes it possible to verify signatures before code is deployed in a serverless computing environment.

Vijoy Pandey, vice president of emerging technologies and incubation at Cisco, said that one of the application security issues that has emerged in serverless computing environments is the lack of validation capability to verify code signatures prior to deployment. As more organizations employ serverless computing frameworks, the overall software supply chain becomes less secure, he noted.

FunctionClarity includes a command line interface (CLI) tool to invoke a verification function that can be deployed on the Amazon Lambda serverless platform to address that issue; support for Microsoft Azure and Google Cloud serverless platforms is planned, he added.

The FunctionClarity project aims to close that gap by employing either a keyless approach using open source sigstore tools or a traditional encryption key, noted Pandey.

The FunctionClarity project is the latest extension of a Cisco OpenClarity initiative that includes an existing project for securing application programming interfaces (APIs) using a service mesh, dubbed APIClarity, and a tool for detecting and managing software bills of materials (SBOMs) and vulnerabilities in container images and filesystems dubbed KubeClarity. All three projects are part of an ongoing Cisco effort to contribute code to the open source community that, while essential, does not provide a lot of differentiated value for any one vendor, said Pandey.

The FunctionClarity project arrives at a time when concerns over the security of software supply chains is on the rise. Many of the software security issues that organizations are encountering stem from the simple fact that developers can provision cloud infrastructure without any kind of meaningful cybersecurity review. Code signing, within the context of a larger set of DevSecOps workflows, is now starting to gain traction to better ensure secure software supply chains. The challenge is that as more code winds up running on serverless computing platforms, a need to extend the reach of whatever approach to code signing an organization adopts becomes more evident.

In general, the open source community is collectively trying to respond to an executive order issued by the Biden administration that required federal agencies to implement a series of steps to better secure their software supply chains. One of those measures includes wider adoption of code signatures to ensure the authenticity of code being incorporated into applications. The challenge is that incorporating code signatures into DevOps workflows has historically not been a trivial process to implement. Most recently, a free sigstore cloud service launched that promised to make it easier to achieve that goal.

It’s not clear how widely or even how rapidly code signing will be adopted, but enterprise IT organizations are paying close attention to how federal agencies are responding to the executive order. Many of the tools and processes defined by those agencies will inevitably be copied by enterprise IT organizations that have thus far made limited use of code signing to verify the authenticity of software components. The challenge now is finding a way to achieve that goal without slowing down the rate at which modern software is developed.

November 8, 2022
Developer’s Guide to Fuzz Testing
Fuzz testing continues to grow in popularity among developers within the open source community. Google’s open source security (OSS) team recently reported finding more than 40,000 bugs in 650 open source projects through the use of fuzz testing. But if you have no clue what fuzz testing is (yet), don’t worry. You’ve come to the right place.

What is Fuzz Testing?

Fuzz testing is a dynamic testing method for finding bugs and security issues in software. During a fuzz test, a program or a function under test gets executed with invalid, unexpected or random inputs to uncover unlikely or unexpected edge cases.

Value of Fuzzing for DevSecOps

As we know, DevSecOps extends the approaches of DevOps and Agile by adding suitable security testing methods alongside every phase of the software development life cycle (SDLC), creating a dynamic and continuous testing process.

Part of that testing process can and should involve fuzzing to detect security and stability issues at all phases of the SDLC and empower developers to ship software quickly and securely. For example, to prevent regressions from going live by running automated fuzz tests on every code change.

Especially in the automotive industry and complex embedded projects, where a lot of untrusted and complicated data gets processed, fuzzing brings excellent benefits to DevSecOps. Indeed, developers can apply fuzzing similar to unit testing to automatically test their security-critical modules for potential vulnerabilities. But with fuzzing on an integration level, they can also cover all the complicated and dangerous edge cases that can occur in the interaction between different modules.

Fuzz Testing Benefits

Fuzzing code generates thousands of automated test cases in a second, with the fuzzer receiving in-depth feedback on code coverage and the program states reached to simulate the interaction of different modules during the execution of the source code. The fuzzer can adapt and mute its inputs based on runtime feedback in the following iterations to maximize code coverage. Some of the benefits are:
1. (Almost) no false positives: If you find a crash, fuzzing provides you with the error source and the malicious input that caused the issue. So, you can be sure that each finding is a real vulnerability.
2. Debug reproducible findings: Modern fuzz testing tools will provide you with the input causing the issue, including the source of the error. With this, you already have a lot of helpful information to reproduce the bug and load it directly into the debugger.
3. Find issues in forgotten edge cases: Because fuzzing is executing a program with invalid or random input, it also uncovers unlikely and unexpected edge case errors that would not otherwise have been revealed.
Who Uses Fuzz Testing?

As cybersecurity regulations and standards continue to expand globally, more and more organizations are extending cybersecurity programs and running automated security testing before they ship software. Whole industries, especially those that involve advanced quality and security regulations, are setting standards for security testing that recommend fuzz testing, including automotive, aviation, finance, healthcare, telco and energy.

Digging deeper into the automotive industry, for example, a variety of International Organization for Standardization (ISO) and other organizational standards now recommend fuzzing:
Best Practices

The most effective way to do security testing, fuzzing included, is to do so continuously. This means integrating fuzzing right into your CI/CD pipeline. Doing so creates quick feedback cycles so developers can fix security vulnerabilities before the code is shipped. Integrating fuzzing tools into code hosting systems like GitHub is also valuable. Doing so allows communication and alerts to be shared across your DevOps team as soon as a problem is uncovered, which helps to facilitate fixing vulnerabilities.

What Bugs Can I Find?

While the practice remains relatively new, fuzzing has already discovered thousands of bugs across different use cases. Bug and vulnerability types discovered include:
- Remote code executions
- Injections, which can be triggered by untrusted inputs
- Memory leaks: Incorrect memory allocation
- Exposure of sensitive data: Accidental exposure of personal data
- Functional bugs: Inputs that are not being responded to
and many more bugs, such as undefined behavior, uncaught exceptions and buffer overflow. Learn more.

Getting Started

You can try out an open source fuzzer, like Jazzer (for Java testing) or the CI Fuzz CLI (for C/C++ testing). When you’re comfortable with fuzzing and want to use this approach in more complex environments, enterprise solutions offer added features like API fuzzing, reporting and CI/CD integration.

So give it a shot and join the community of open source developers using fuzzing to quickly and securely ship their software.
November 8, 2022
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

ZipRecruiter.com

Comcast
New York City
Lead Software Engineer – DevOps
$190,950 to $225,278

Indeed.com

Divi Technologies
Remote
DevOps Engineer
$140,000 to $155,000

SimplyHired

Perimeter 81
New York City
DevOps Engineer
$130,000 to $175,000

Dice.com

OnDemand Group
Minnetonka, MN.
Senior DevOps Engineer
$120,000+

LinkedIn

Gainwell Technologies
Remote
Senior DevOps Engineer
$92,500 to $115,600

November 7, 2022
Introduction to SPIFFE/SPIRE

For a long time, people have been logging into the apps they use via passwords or password managers. And many open standards and identity providers on the market continue to evolve how users authenticate and authorize with websites and applications. The issue is that the same problem exists for software services—when applications talk to applications, how do we prove the credibility of service-to-service connections?

Enter SPIFFE and SPIRE. SPIFFE is a specification for implementing identity for workloads, and SPIRE is the code that implements this specification in practice. Together, the projects create a standardized, secure way to identify software services and authenticate them. SPIFFE and SPIRE recently reached graduation status with the Cloud Native Computing Foundation (CNCF), solidifying the projects’ maturity as a top open-source standard mechanism to deliver cryptographic runtime identity for both cloud-native and legacy workloads.

SPIFFE and SPIRE are already used across many major public deployments. Yet not all developers are familiar with their intricacies. Below, I’ll take a gander at both projects and how they operate to provide a bit more context. I also spoke with Evan Gilman, SPIFFE/SPIRE maintainer, to gather more insights on the history of the projects and their future goalposts.

What is SPIFFE?

The Secure Production Identity Framework For Everyone (SPIFFE) is a specification for workload identity. According to Gilman, the easiest way to think about SPIFFE is as a passport. Similar to how people are issued passports in a common shape with a barcode and standard information, SPIFFE dictates the standard methods to prove and validate the identity of a service. It’s like bringing the “Sign in with Google” experience to the software services themselves, he adds.

There are three key components in SPIFFE. First, SPIFFE specifies that services shall identify themselves with what’s called a SPIFFE ID, which is defined as a URI in the format of spiffe://trust-domain-name/path. These IDs are then encoded into a SPIFFE Verifiable Identity Document or SVID. SVIDs aren’t so much a document type themselves — instead, they support either X.509 or JWT document types. Last but not least, SPIFFE specifies a workload API that issues and rotates these SVIDs, along with the keys needed to validate them.

What is SPIRE?

SPIRE is the code that implements the SPIFFE specification—you can think of it as a production-ready SPIFFE runtime environment. SPIRE, the “flagship SPIFFE implementation,” is a true end-to-end instantiation of SPIFFE that securely issues SVIDs, renews SVIDS and performs attestation, among other functions. If SPIFFE defines what a passport is, then SPIRE is the agency that issues the passports, said Gilman.

The SPIRE agent runs on a node and exposes the workload API, which hooks into each workload. A workload, as defined by the SPIFFE documentation can be a web server, an instance of a MySQL database, a worker program or a web application composed of independently deployed systems. By communicating in this manner, SPIFFE/SPIRE can solve the issue of “secret zero,” which refers to the conundrum of proving the first credential to newfound systems.

More Background on SPIFFE/SPIRE

Joe Beda, a co-founder of Kubernetes, first proposed SPIFFE at GlueCon in 2016. At the time, Google was considering what internal technology it had that might prove helpful to the broader industry. It’s said that the technology that inspired SPIFFE/SPIRE can trace its roots to security and identity subsystems brought to Google from AT&T and Bell Labs.

Nowadays, SPIFFE/SPIRE is actively maintained by many organizations, and we continue to see impressive production use cases. “SPIRE is deployed in some staggeringly large cases,” explained Gilman. SPIFFE/SPIRE adoption can be seen within GitHub, Netflix, Pinterest, Square, Transferwise, Uber and many other large technology companies. In terms of ownership, Gilman said that SPIRE is most used by platform engineers, infrastructure engineers or security engineers, depending on the organization’s roles.

Future Outlook for SPIFFE and SPIRE

SPIFFE/SPIRE appear to have the resources and backing to maintain a stable implementation, so the future looks bright for both projects. In terms of new features, in mid-2022, a first-class integration with SPIRE was merged into the Istio service mesh as a more flexible alternative to Istio’s built-in SPIFFE implementation. Another recent update is experimental support for SPIRE on Windows. Regarding future plans, SPIFFE/SPIRE maintainers will likely continue to iteratively improve the specification and implementation with frequent updates.

November 7, 2022
OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

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 OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)

November 3, 2022
Opsera Brings DevOps Intelligence to GitHub Actions

Opsera today announced it has extended its platform for collecting DevOps intelligence to include support for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

Opsera CEO Kumar Chivukula said as GitHub Actions is adopted more widely, there is a growing need to provide greater visibility into Git-based workflows in real-time. A GitHub Actions Insights module for the Opsera platform makes it possible to track key performance indicators (KPIs) across those workflows, he added.

The goal is to make it simpler to make data-driven decisions about how best to optimize those workflows by identifying bottlenecks, noted Chivukula.

The Opsera platform surfaces that intelligence by scanning all repositories and branches, including commit history, and generating alerts and notifications whenever KPI thresholds or compliance requirements are exceeded. DevOps teams can also use the platform to assess their overall DevOps maturity using a set of DevOps Research and Assessment (DORA) metrics defined by Google. Going forward, Opsera also plans to start surfacing metrics based on the Supply chain Levels for Software Artifacts (SLSA) framework for securing software supply chains also defined by Google.

Platforms such as Opsera make it possible to apply analytics to DevOps workflows as they become more complex. The number of dependencies that exist between various application modules, for example, makes it exceedingly difficult for DevOps teams to manually identify the impact a delay in one project might have on any number of other downstream projects.

In addition, many organizations are keen to discover what best practices should be adopted by other application development teams.

Finally, many developers tend to use a repository as a dumping ground for all kinds of software artifacts, noted Chivukula. DevOps teams need an intelligence tool that makes it possible to identify which of those artifacts are the most essential to the business, he added. Otherwise, manually combing through a repository looking for artifacts becomes the DevOps equivalent of looking for a needle in a haystack, noted Chivukula.

GitOps is essentially a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform. It’s not clear how much traction GitHub Actions is gaining at the expense of other CI/CD platforms, but for organizations that are relatively new to DevOps and already using GitHub as a code repository, it presents a path of least resistance.

Regardless of why organizations adopt a DevOps intelligence platform, the need to optimize workflow across toolchains is becoming more pressing during an economic downturn. It’s becoming more clear that the cost of an application delivery delay directly impacts the level of revenue an organization generates in the age of digital business transformation.

November 2, 2022
Know What You Want and Need

Over the years, what we purchase from vendors has changed significantly. It used to be that IT would define a need, go out and find a bit of software to solve it, install and configure the software and, in most cases, spend the majority of time on the project getting it to work correctly in their environment. Those days are largely gone. First, we started buying appliances for some functionality, then we started using MSPs for some or all functionality, then some vendors wanted to deliver in a VM where they could make configuration much easier by controlling the environment. That was the first step to virtualizing purchases. Then we started looking at infrastructure-as-a-service (IaaS), then SaaS, then some vendors offered PaaS … Currently, all of the cool vendors are offering containers—which are an improvement over VMs, and offer a virtual appliance that is quick to get running and tested to do what it was purchased for. Or at least tested to do what it was sold for. We’ve all got stories about what we did with these purchases that were “off label”—things that a product really wasn’t designed for. Along the way, we also introduced open source vendors; a bit of an oxymoron that really described service orgs that base their product on an open source project. Some far more successfully than others.

And all of that, dear reader, is why we are here. Before purchasing, there is a lot more to find out than there used to be. What, actually, is the product this software vendor is selling? In the end, IT is looking to solve a problem. Most of the time, whether that problem is solved by SaaS, local install or cloud instance is less important than how well the problem is solved. But implementation—and licensing—are important to an organization if not immediately, then over the long term.

When purchasing an open source “product”, you’re … actually not. You are getting the product and purchasing support. Since open source can be hacked to run just about anywhere given enough time, more than one OSS vendor has pretended that makes them superior to commercial products targeted at a specific platform. That is blatantly untrue—unless the OSS vendor is supporting the product anywhere and everywhere which, of course, they are not. I can port the OSS project MyFunApp to any platform I want without paying for support that won’t do a thing for me when I get it up and running on OS/2 (as an extreme non-existent example).

SaaS has more issues when it comes to TCO. While pay-as-you-grow is cool and all, locking in a monthly payment forever is a big step and should be considered. And at an enterprise, “forever” needs to be considered realistically. Implement a particular SaaS CRM and you are unlikely to move to another, even if you claim that you will in a heartbeat. It’s work. A lot of work. It is definitely possible, but for most organizations, unlikely. So know what you are getting into. And while you are evaluating, don’t forget to consider variable charges, which most SaaS products have. Make certain you understand what the actual monthly costs are likely to be. IaaS suffers this same variability problem, as many of us have learned.

Containers are a very sweet solution to appliance-like functionality—drop a container into your Kubernetes flavor of choice and move along. The problem here is a combination of proliferation—how many are required? One per pod can get expensive over time, for example. Those resources aren’t free, no matter the platform. The other issue is updates. Automatic updates are the norm for container instance-delivered products. From a security perspective, you should have questions. Updating things in your network should probably require your approval.

I’m not suggesting that one delivery method is better than others here; I’m simply suggesting that we all need to be more deliberate about those choices than we’ve needed to be in the past. Knowing not just SLAs but the cost and support implications of every choice is important both today and down the road.

Keep kicking it, and keep picking the solutions that best solve the organization’s problems. Just be aware that sometimes, the issues a delivery method introduces undermine the effectiveness of the solution.

November 2, 2022