devopsy.kinsta.cloud

Author: Mike Vizard

  • Okta Offers PASETO as Alternative to JSON Tokens

    Okta Offers PASETO as Alternative to JSON Tokens

    Okta today launched an open source library for using Platform-Agnostic Security Tokens (PASETO) as an alternative to JSON Web Tokens (JWT) to authenticate end users.

    Randall Degges, head of evangelism for Okta, said PASETO is quickly emerging as an easier, more secure implementation of the JWT specification. PASETO is a draft specification created by Scott Arciszewski that reduces the scope of the Javascript Object Signing and Encryption (JOSE) family of specifications in a way that makes it easier for developers to embrace tokens to secure application access.

    Okta is trying to make it easy for developers to employ PASETO using a library written in Java, dubbed JPASETO, that has half the lines of code JWT token written in Java and is supported by a vendor, he said.

    While JWT tokens have been widely adopted, they are easy to misconfigure, which Degges noted has resulted in the recent discovery of many JWT vulnerabilities. Part of the fault for those vulnerabilities lies with the JWT specification itself, he added; JWTs support a wide range of cryptographic algorithms, including an option that employs no cryptography at all.

    In contrast, Degges said PASETOs are more cryptographically resilient and far easier to employ. The PASETO specification defines two types of tokens: local and public. Local tokens are always symmetrically encrypted with a shared secret key, which means no one can view the contents of a local PASETO unless they have the correct secret key. Public tokens are readable by anyone and are validated with a public key. There is no “none” option; there can’t be a security token that is not encrypted, he said.

    All PASETO formats are designed to be tamper-proof. The entire message is authenticated, so validation will fail if anything in the token changes, added Degges.

    That approach ensures higher levels of application security while at the same time aiding in the adoption of best DevSecOps practices using Okta’s JPASETO library, which can be incorporated easily into the application development process, he noted.

    In recent years software tokens such as JWT have gained traction as a way to implement two-factor authentication in place of creating a session in the server and returning a cookie. When a user successfully logs in using their credentials, a JSON Web Token is returned and must be saved locally.

    Software tokens, however, can still be vulnerable to attacks that either duplicate the underlying cryptographic software or phishing attacks that trick end users into giving up a password. There is no such thing as perfect security; however, software tokens provide a critical layer of security that should be employed much more widely.

    It’s not clear to what degree PASETO will further that goal. Many organizations may even mandate the use of either JWT or PASETO as part of their overall approach to DevSecOps. Regardless of approach, it’s clear that continuing to rely on sessions and cookies to authenticate end users is an antiquated approach to authentication that is not only more difficult to implement and manage but also ultimately less secure.

  • Arrcus Expands Network Services Spanning Hybrid Clouds

    Arrcus Expands Network Services Spanning Hybrid Clouds

    Arrcus has added virtualized distributed routing (VDR) and multi-cloud networking (MCN) capabilities to ArcOS, a network operating system (NOS) that can be deployed on-premises or in the cloud.

    Company CEO Devesh Garg said these additional capabilities provide the programmatic network services that IT organizations require to foster deployments of hybrid cloud computing environments.

    Arrcus MCN provides the ability to securely connect workloads and data across any cloud, while VDR eliminates the need to rely on physical routers that require their own chassis, he said.

    Arrcus has been making the case for a disaggregated approach to networking that eliminates dependencies on physical infrastructure. Instead, IT teams can deploy ArcOS on a cloud service or any white-box appliance they choose in an on-premises IT environment. That approach eliminates the possibility of becoming locked into specific network hardware platforms, he said.

    Garg added it also provides DevOps teams with a consistent foundation on which to deploy distributed applications. Rather than having to navigate different NOSes running in the cloud and on-premises IT environments, ArcOS presents a consistent set of application programming interfaces (APIs) for accessing network services.

    In fact, the need to programmatically invoke those network services is what’s driving the convergence of network operations and DevOps teams, he noted. As applications become more distributed in the age of the cloud, IT organizations are looking for more efficient ways to expose network services on-demand.

    That convergence, however, will take time. Many networking teams still tend to prefer to acquire routers and switches as physical devices that include a NOS rather than deploying an operating system on infrastructure they select and manage. However, as DevOps teams continue to push for access to network services that can more easily scale up and down as required, it’s now only a matter of time before software-defined networking services become a default requirement.

    In fact, Garg said, the rise of microservices will force that issue as DevOps teams look to deploy applications that will be updated frequently.

    In addition, he noted, the rise of edge computing platforms and 5G wireless networking services will simultaneously push organizations toward virtualized network services.

    It’s not clear at what rate network services are being transformed. Software-defined networking services are already readily available in the cloud. Progress in on-premises IT environments has been tied to the willingness of IT organizations to fund upgrades to core network infrastructure. The challenge many IT organizations now face in the wake of the economic downturn brought on by the COVID-19 pandemic is finding a way to achieve that goal cost-effectively. White-boxes provide a less costly alternative to switches from vendors such as Cisco Systems and Arista Networks. At the same time, the total cost of delivering network services across a hybrid cloud computing environment can decline when a common NOS is employed across all platforms.

    Regardless of the path forward, the one thing that is certain is legacy network infrastructure has become a major bottleneck at a time when IT organizations need to be more agile than ever.

  • Vercel Makes Front End Applications Faster

    Vercel Makes Front End Applications Faster

    Vercel this week extended its effort to redefine how front-end applications are developed to reduce dependencies on backend systems.

    The company has created Next.js, which makes it possible to build web applications using a framework based on the React library for creating user interfaces that enable both static generation (SSG) and server-side rendering (SSR). The latest version a Vercel Edge platform based on Next.js has been re-architected to provide faster routing and better caching.

    Vercel CEO Guillermo Rauch said that capability results in a 10x performance improvement that, among other things, enables applications that employ the React framework for user interfaces to automatically pre-render, code-split and hot-reload, with no configuration required.

    Fresh off raising $21 million in funding, Vercel is committed to making it easier to build highly interactive applications that run in real-time by leveraging Next.js, Rauch said. Vercel claims there are more than 30,000 sites running Next.js in production at organizations such as Airbnb, Hulu, Nike, Ticketmaster and Uber.

    Rauch said most developers are looking to take advantage of frameworks that enable them to treat the underlying IT infrastructure as if it were serverless whenever possible using a familiar JavaScript-type tool.

    At the same time, Vercel is making it possible to run Next.js on a local host, which enables integration with React Refresh from Facebook to enable real-time page change visualization on local hosts. New pages can also be pushed automatically whenever data changes. In addition, developers can replicate all the customized functions from a cloud on a local host.

    Finally, the distributed caching provided via Vercel’s content delivery network (CDN) eliminates the need to rely on legacy CDNs that often require repetitive round trips, he said.

    As frameworks such as Next.js are embraced, DevOps teams will need to adjust to applications capable of providing richer application experiences without relying as much on backend infrastructure. That shift has implications for everything from the amount of network bandwidth consumed to the performance of web applications. Rather than continually focusing on backend infrastructure to optimize application performance, Rauch said the Vercel platform employs caching, routing and a React framework to optimize application performance.

    It’s not clear whether or how much DevOps teams will nudge developers toward frameworks such as Next.js to develop web applications. In theory, the more efficient web applications are the less time and effort that will be needed to monitor applications. In addition, the overall size of the backend IT environment might not need to be as large.

    One way or another, however, the way web applications are developed is evolving. That doesn’t mean JavaScript-based frameworks will eliminate the need for programming languages such as Java. However, the preponderance of applications relying on Java to invoke backend services soon might be reduced substantially.

  • Snyk Tool Prioritizes Open Source Vulnerabilities

    Snyk Tool Prioritizes Open Source Vulnerabilities

    Snyk today announced it has enhanced the ability of its namesake vulnerability scanning tool by adding the ability to identify which open source vulnerabilities should be fixed first using a scoring tool that leverages data science and machine learning algorithms to analyze code.

    In addition, DevOps teams can now take advantage of automated pull requests to fix those vulnerabilities.

    Finally, DevOps teams also can define policies that require certain classes of vulnerabilities to be fixed whenever they are identified.

    Aner Mazur, chief product officer for Snyk, said given the number of open source modules employed and the dependencies that exist between them, staying current on patches and updates has become a major challenge. The only way to achieve that goal is to rely more on tools that help automate that process, he said.

    These days it’s easy for development teams to feel overwhelmed by patch requests to fix open source security vulnerabilities. The trouble is, not all those requests are of equal weight. Snyk provides tools that enable developers to understand which vulnerabilities are of the highest severity and how they might impact their code.

    Armed with that insight, Mazur said, it then becomes possible to prioritize remediation tasks within the context of a DevSecOps process. Otherwise, developers will simply fix vulnerabilities regardless of relevance as time allows. Developers may remediate dozens of bugs only to discover that a critical flaw that had been left unaddressed led to a major compromise.

    It’s also not uncommon for DevOps teams to fail to appreciate dependencies between open source code modules. When patches to code are applied in the wrong order, an application can break, resulting in DevOps teams having to start the whole process over. The prioritization tools provided by Snyk prevent that from occurring, Mazur said.

    In the absence of any ability to prioritize vulnerabilities, developers eventually become inured to patch requests because they don’t know whether their patching efforts are making any real difference, he added.

    Worse yet, all the time spent on patching low-level vulnerabilities reduces the amount of time developers have available to write new application code. In fact, one of the paradoxes of DevOps is as the number of applications deployed increases so too does the amount of time spent debugging them. Before too long, a DevOps team can find itself spending more time fixing existing code than developing new applications.

    As DevOps teams become more dependent on open source code, they benefit from the collective security efforts of all the contributors to that project. The result is more secure code, as patches to remediate specific issues are made available. The challenge now is finding a way to automatically apply those updates in a way that doesn’t conspire to slow down the overall application development process. Achieving that goal requires visibility into what is now a multitude of open source projects that no DevOps team is ever going to be able to consistently achieve on its own.

  • observIQ Lauches Open Source Log Agent Project

    observIQ Lauches Open Source Log Agent Project

    Blue Medora, after selling its core monitoring integration platform to VMware, today changed its name to observIQ and launched an open source agent project that will serve as the foundation of a log management tool to be delivered as a software-as-a-service (SaaS) application.

    Company CTO Mike Kelly said the observIQ agent, which is written in the Go programming language, will provide IT teams with access to highly configurable agent software that doesn’t adversely impact performance. In contrast, existing open source log agent software requires IT teams to sacrifice one for the other, he said.

    Because the observIQ agent is highly configurable, it will also serve to make it easier to collect a wide range of metrics that can be consumed by a wide variety of management tools, Kelly added.

    The company will employ observIQ to collect metrics for observIQ Cloud, a SaaS platform currently in beta, in addition to continuing to invest in BindPlane, an IT operations data management platform developed by Blue Medora that delivers a relationship-aware stream of metrics and logs in real-time.

    Kelly said IT teams need access to a highly configurable agent software because the types of metrics that need to be collected continue to expand and evolve.

    At the same time, Kelly notes IT teams need to be able to affordably instrument many more applications, which becomes difficult to achieve when relying on commercial agent software.

    Finally, as IT environments become more complex, organizations are embracing best DevOps practices to manage applications, which requires organizations to increase dramatically the level of observability they have into any application environment. The issue DevOps teams encounter is they wind up having to support multiple agents, so if an open source project leads to fewer agents that need to be maintained and updated, that might be a benefit that resonates.

    In the meantime, as log management heads into the cloud along with most other IT management services it’s also becoming easier for IT teams to manage applications from anywhere. Most IT teams are going to be working remotely much more often than they did prior to the onslaught of the COVID-19 pandemic. That transition is easier to achieve when the tools being relied on reside in the cloud.

    Many IT teams also tend to limit their use of log analytics because of the costs associated with storing and collecting data. To limit those costs many IT organizations opt to only store log data for a limited time or only collect metrics for their most critical applications. The challenge is, the percentage of applications deemed critical continues to increase.

    Of course, competition across providers of log management tools that can be accessed as a service is already fierce, so observIQ will have its work cut out establishing another platform. However, if DevOps teams adopt its open source agent software, there’s naturally a much higher chance organizations will wind up employing observIQ Cloud.

  • Puppet Brings Orchestration to IT Automation

    Puppet Brings Orchestration to IT Automation

    Puppet today unveiled its summer release of Puppet Enterprise that promises to make it easier for DevOps teams to construct automated workflows within a Puppet console.

    DevOps teams can now mix and match thousands of declarative state-based modules available on Puppet Forge repository to compose and orchestrate workflows.

    At the same time, Puppet has added out-of-the-box guided patch management workflows that replace standalone patch management tools with orchestrated workflows. That capability is based on a Relay tool that Puppet launched earlier this year.

    Finally, Puppet is now also including an upgrade pre-check module that assesses and identifies potential risks along with surfacing what changes should be made before running an upgrade.

    Puppet CTO Deepak Giridharagopal said in the wake of the economic downturn brought on by the COVID-19 pandemic, more IT teams will need to rely heavily on automation. Most IT teams either will remain the same size or be downsized. The IT environment, however, will continue to grow more complex. The only way to enable IT teams to do more with less is to automate more rote tasks, he said.

    Automation is not likely to replace the need for IT administrators, added Giridharagopal. Rather, investments in automation will augment those teams in a way that enables IT teams to scale.

    In fact, Giridharagopal said, resistance to IT automation is declining as IT teams continue to appreciate the scope of the challenge they now face as IT environments not only continue to expand but also become more heterogeneous. Most business leaders now expect smaller IT teams to be able to automate a wide range of tasks as part of their overall strategy, he noted.

    Longer-term, Giridharagopal said IT organizations will also discover that many rote tasks will be performed more consistently once automated. Patches, for example, are not always applied as quickly or as often as they should be simply because there isn’t enough time for the IT team to manually install them.

    The latest update to Puppet Enterprise comes on the heels of a $40 million investment made in Puppet led by BlackRock, a private equity firm. As more IT teams recognize the need to automate tasks, competition to automate those tasks has intensified among providers of frameworks.

    It’s not clear how deeply and how many IT tasks can be automated. The more standardized an IT environment is, the easier it becomes to automate. Additionally, the amount of time an IT organization devotes to writing scripts to automate tasks should be reduced sharply. Instead, IT teams will increasingly employ a mix of modules that already exist to address a broad range of use cases. The challenge going forward isn’t so much finding the right IT automation tool, but rather constructing an IT environment that lends itself to being automated.

  • Apollo GraphQL Brings Caching to Client Software

    Apollo GraphQL Brings Caching to Client Software

    Apollo GraphQL this week updated its namesake GraphQL client software that among other things improves performance using in-memory caching application programming interfaces (APIs).

    GraphQL has emerged as a popular alternative to REST APIs because it provides developers with a query engine that provides more control over what data is requested. Similar in concept to SQL, developers GraphQL also makes it possible for developers to describe the data they are exposing via an API.

    Finally, GraphQL APIs are organized in terms of types and fields rather than endpoints. That allows developers to organize APIs within a graph that makes them available via a single request rather than requiring every communication between APIs to occur on a point-to-point basis.

    Apollo GraphQL has created client software that allows developers to employ GraphQL to both query external data in addition to making use of a graph to catalog the services made available within the front end of an application.

    Version 3.0 of Apollo GraphQL client software addresses a caching limitation that stems from the fact generic HTTP caching doesn’t work with GraphQL. Every time an HTTP request is made for slightly different data the cached value is invalidated. When the Apollo GraphQL client fetches data from your server it caches that data using a normalized structure that matches the Apollo GraphQL schema, which allows it to locally reconstruct a subset of the back-end data graph. The next time Apollo Client queries any of that same data it can fetch it directly from the cache.

    Developers can now also define a field policy for any GraphQL field that appears in your cache. A field policy can include a read function that customizes what occurs when the field is read from the cache and a merge function that customizes what occurs when it’s written.

    Apollo Graph CTO Matt DeBergalis said by defining all of this custom field logic in one place developers can avoid repeating code. Other developers can also interact with the types and fields without needing to understand how they’re stored or fetched, he said.

    Version 3.0 of the Apollo client library also now includes support for a reactive variable value that registers a dependency when read.

    Originally developed by Facebook, GraphQL is gaining a lot of traction on backend systems because it allows developers to describe the data that can be accessed. However, because it also makes it more efficient to query data it’s also now being more widely deployed on clients as well. It’s not clear to what degree REST APIs might be replaced by GraphQL, but at the very least reliance on REST APIs in new application development projects is likely to decline significantly.

    The implications of that transition for DevOps teams are significant because the overall performance of applications that rely on GraphQL versus REST APIs should substantially improve. In fact, the biggest inhibitor to GraphQL adoption at this juncture may be simple inertia. Too many developers simply build REST APIs as a matter of reflex without necessarily investigating alternatives. However, it should not be too long before everyone on the DevOps teams starts to appreciate just how much the end user experience really is when GraphQL is employed.

  • OverOps Partners With GitLab to Analyze Code Earlier

    OverOps Partners With GitLab to Analyze Code Earlier

    OverOps has allied with GitLab to integrate a tool that analyzes code at runtime to identify issues with a continuous integration/continuous delivery (CI/CD) platform.

    Eric Mizell, vice president of solution engineering for OverOps, said the plugin for the GitLab CI/CD will make it easier to surface issues with code earlier in the DevOps pipeline. OverOps’ quality gates help determine if code is safe to promote and automatically blocks unstable releases from moving forward to production.

    OverOps combines static and dynamic analysis of code as it executes by relying on machine learning algorithms to collect data. That analysis can be accessed either via dashboards based on open source project Grafana software or shared with other tools via an open application programming interface (API). It analyzes code at runtime to identify all new, increasing, resurfaced and critical errors in a release. OverOps then generates a code quality report that ranks issues in terms of potential to impact end users and application functionality.

    According to a recent survey of more than 600 software development and delivery professionals conducted by OverOps, more than 50% of respondents spend a day or more per week troubleshooting code-related issues.

    The survey also finds that nearly 25% of organizations experience critical/customer-impacting production issues on a daily or weekly basis.

    The earlier code issues are detected the less expensive they are to fix. OverOps is making the case for making its tool part of the quality assurance gate within any CI/CD pipeline.

    The paradox many organizations find themselves in is that as DevOps processes enable them to build and deploy applications they wind up spending a lot more time debugging those applications.

    Eventually, developers wind up spending more time fixing existing application code than developing new applications. Tools such as OverOps are employing machine learning algorithms to reduce the amount of time spent discovering code issues, which should free up more time to write new code.

    OverOps captures machine data about every error and exception at the moment it occurs, including details such as the value of all variables across the execution stack, the frequency and failure rate of each error, the classification of new and reintroduced errors and the associated release numbers for each event.

    DevOps teams historically rely on log data to manually search for anomalies indicative of issues with code. Not only is OverOps faster, but the algorithms will also surface uncaught and swallowed exceptions that would otherwise be unavailable in log files.

    There are a lot of aspects of DevOps that now can be better handled by machines than humans. That doesn’t mean humans will be replaced anytime soon. However, the bulk of time-consuming and monotonous DevOps tasks that exist today are eventually going to be performed by a machine faster and with greater precision. The challenge and opportunity now are identifying the tasks where machine learning algorithms can have the most impact sooner than later.

  • Barracuda Networks Partners With Microsoft on SD-WAN Service

    Barracuda Networks Partners With Microsoft on SD-WAN Service

    Barracuda Networks today launched a software-defined wide area network (SD-WAN) service that runs natively on the Microsoft Azure cloud.

    Klaus Gheri, vice president of network security for Barracuda Networks, said Microsoft has made it possible to launch an SD-WAN service using Azure Virtual WAN Hubs, a networking service based on a hub-and-spoke architecture that unifies networking services such as security and routing under a common interface. Those services span branch connectivity, multiple types of virtual private networks, cloud interconnects, firewalls and encryption services.

    Gheri said rather than having to replicate all those networking services, Barracuda Networks is layering a Barracuda CloudGen WAN service on top of the Azure Virtual WAN Hubs to provide a service that, like any other cloud service, can be consumed per billable hour.

    Developed in collaboration with Microsoft, the Barracuda CloudGen WAN service provides the management framework needed to convert Azure Virtual WAN Hubs into an SD-WAN service that IT teams can employ to securely connect remote offices to cloud applications or on-premises IT environments, he said.

    SD-WAN services today come in four basic forms. IT teams can deploy and manage their own SD-WAN appliances. Alternatively, telecommunications carriers make SD-WAN services available on their networks or a managed service provider (MSP) can create its own SD-WAN service by deploying the appliance on points of presence (PoP) on a global network it manages. More recently, cloud service providers have been making SD-WAN services available via the networks they built to connect all their data centers.

    Gheri said Microsoft is now taking that SD-WAN capability a step further by adding a management portal created by Barracuda Networks.

    A recent survey of 750 business and IT professionals conducted by Vanson Bourne on behalf of Barracuda Networks finds more than half (52%) are looking to employ SD-WAN services delivered via the cloud. In comparison, the survey finds 16% prefer to get SD-WAN from an independent vendor, 15% would opt for a telecommunications partner and 12% would rely on a value-added reseller.

    With more application workloads moving into the cloud, the way networks are deployed and managed is evolving rapidly. Instead of connecting branch offices to local data centers to access cloud applications, more organizations are employing SD-WANs to provide direct access to cloud applications without having to backhaul network traffic through a local data center. That approach significantly improves overall application latency and, in many cases, reduces the need to rely on leased MPLS lines from a telecommunications carrier.

    Rather than build those SD-WANs themselves, many IT organizations want to be able to access and manage them via a portal through which they can allocate bandwidth to applications as they best see fit. It’s not clear to what degree IT organizations will continue to prefer to deploy appliances versus consuming SD-WAN as a service. However, given the complexity of managing SD-WANs, there’s a high probability that SD-WAN services delivered via existing cloud networking infrastructure will soon become a widely employed alternative.

  • RunSafe Allies With JFrog to Secure Applications

    RunSafe Allies With JFrog to Secure Applications

    RunSafe Security, a provider of Alkemist tools that prevent memory exploits, has partnered with JFrog to create a plug-in for the Artifactory repository manager platform.

    Alkemist employs a combination of runtime application self-protection (RASP) and moving target defense (MTD) methods to neutralize memory corruption exploits such involving, for example, a memory overflow.

    Based on a research project for the Advanced Research Projects Agency of the Department of Defense (DARPA), the integration with Artifactory will make it easier to harden binaries and containers against memory corruption attacks before applications are deployed in a production environment, said RunSafe CEO Joe Saunders.

    RASP describes a class of application security tools that detect attacks in real-time as an application is running. MTD refers to a strategy that relies on changing the attack surface regularly for applications to make it more difficult for cybercriminals to target them.

    Cyberattacks that employ memory exploits attempt to either replace executables with malicious code or overwrite data in a way that changes application behavior. When aimed at operating systems, these attacks commandeer entire systems. They have also been used to launch self-replicating Worm attacks that both cripple systems and insert malware to steal data, corrupting files or installing a back door that enables remote access.

    Saunders said the Alkemist plugin will enable developers to defend applications from these types of attacks without slowing down the pace of application development. Friction is removed from the DevOps process because as code moves through the DevOps workflow, Alkemist automatically hardens it to prevent memory exploits, he said.

    With the growing popularity of containers, Saunders noted that as cybercriminals begin to target them the need to protect containerized applications from memory exploits using best DevSecOps processes will become even more pronounced than it is today.

    While there is clearly a lot of interest in DevSecOps, most developers still don’t have access to the tools needed to better secure applications. As more cybersecurity plug-ins become available for repositories such as Artifactory, the easier it will become to embrace best DevSecOps practices.

    JFrog, for its part, has been making a case for focusing DevOps teams on managing binaries rather than source code. The alliance with RunSafe extends that strategy into the realm of application security.

    It may be a while before DevSecOps practices are widely employed. However, increasingly the issue is becoming less about the tools that might be available. Rather, the cultural challenges associated with implementing cybersecurity gates within a DevOps pipeline is now the major challenge. DevOps teams will need to reconstruct existing DevOps workflows to incorporate cybersecurity gates before an application is deployed. Once that’s accomplished, monitoring applications for anomalies will then need to be incorporated into observability platforms.

    It’s not clear what role cybersecurity professionals will play in this new world of DevSecOps. The one thing that everyone can agree on, however, is the less involved cybersecurity professionals are in the application development and deployment process, the easier it should become to deploy applications that are truly secure.