devopsy.kinsta.cloud

Category: DevOps Practice

  • 15 DevSecOps Best Practices

    15 DevSecOps Best Practices

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

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

    1. Secure your application development process

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

    2. Protect your production environment

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

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

    3. Implement least-privilege principles

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

    4. Use role-based access control (RBAC)

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

    5. Encrypt sensitive data

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

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

    6. Use two-factor authentication

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

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

    7. Use secrets management tools

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

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

    8. Train your employees in security awareness

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

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

    9. Use a web application firewall (WAF)

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

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

    10. Perform regular security audits

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

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

    11. Use intrusion detection and prevention systems (IDPS)

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

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

    12. Implement a disaster recovery plan

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

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

    13. Use logging and monitoring tools

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

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

    14. Conduct regular penetration tests

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

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

    15. Use access control lists

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

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

    Conclusion

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

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

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

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

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

  • The Argo Project: Making GitOps Practical

    The Argo Project: Making GitOps Practical

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

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

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

    What is GitOps and Will it Replace DevOps?

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

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

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

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

    What is the Argo Project?

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

    The Argo project consists of four main sub-projects:

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

    Requirements for Kubernetes in Production

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

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

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

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

    Benefits of Argo Tools for Production Environments

    Argo CD

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

    Argo CD key features include:

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

    How does Argo CD make Kubernetes production ready?

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

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

    Argo Rollouts

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

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

    How do Argo Rollouts make Kubernetes production ready?

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

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

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

    Argo Workflows

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

    Key features of Argo Workflows include:

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

    How do Argo Workflows make Kubernetes production ready?

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

    Argo Events

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

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

    How do Argo Events make Kubernetes production-ready?

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

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

    Conclusion

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

  • DevSecOps Tools: Hot Air Ahead

    DevSecOps Tools: Hot Air Ahead

    I, like most of you, don’t like hardcore marketing that hinges its statements on “Well, that’s technically true…” I also am not a fan of talking heads that spew predictions about the future. Sure, they’re right sometimes; that’s because we have so many people pontificating that random distribution means some will be correct. I am bringing all this up to warn you that I (basically a high-tech talking head) am about to talk about tools, the future of tools markets (one in particular) and what I think should/will happen.

    Sometimes, talking about the future of a given tech is done to make a name for yourself. I don’t play that game. My goal is simply to say, ‘This is what I would like to see, and why I would like to see it.’

    Enough spewing—let’s talk about DevSecOps tools. I jotted down this topic a while back when I touched briefly on it, and my ideas firmed up while working on a recent project.

    Let’s start easy. If you are not using what we currently call DevSecOps tools in your DevOps toolchain, go get them set up. Go ahead, we’ll wait. It’s that much of a no-brainer that we’ll sit here while you choose, purchase and install your choice. Seriously. “Here is a tool that will make development more secure and make developers more productive.” Go install it now. Choose what functions you want to use and work them into your toolchain.

    But don’t get too married to your vendor. Because for the very same reasons I just told you to go install them, I will say I don’t think they should be a standalone market. Here is a toolset that plugs into the IDE on one end, and runs stand-alone, integrated with CI/CD on the other. It is DevOps in many ways. And while code scanning is inarguably a security function, the spirit of DevOps overall is “Who cares?” Using these tools shifts quite a bit of security functionality left and also warns about bad coding practices. Note I did not specifically say insecure coding practices, though those are covered. I said bad coding practices. The largest of these vendors will let you know things like, “Hey, you sent that variable to this function and then never used it. Are you sure?” or “This loop looks like it never exits. Are you sure?”

    It should be, and I predict will be, part of the DevOps process. In my dream world, the functionality would get split and some would end up in IDEs, while the rest would end up in testing tools or CI tools. But that’s not normally how markets get split up when there are established vendors. Even though you can feel the difference in the functionality (a bunch of them plug right into the IDE; the rest don’t), it won’t get split up because existing markets generally merge through acquisition. So we’ll have to see how things fall out, but I’m betting on CI/CD vendors or system-wide security vendors moving into this market. Indeed, companies with a SOC will likely find these vendors appealing because most of them also operate SOCs for the dynamic scanning part of the system.

    Still don’t have DevSecOps installed? Go now. Choose a vendor.

    Because I’m being so forceful about telling you to install one of these toolsets, I’ll state very clearly: At the time of this writing, I do not have any kind of relationship with any vendor in this space. I say this because I use the tools and strongly believe that the pain points they bring as a layer in development are very much made up for by the benefits they bring to the application.

    And keep rocking it. This will just make your systems more stable, and the merges (that I see as inevitable, but is actually only a possibility) you can worry about when they come along.

  • Retaining Talent as the Developer Role Evolves

    Retaining Talent as the Developer Role Evolves

    Traditional development roles are rapidly evolving due to increased remote work and the Great Resignation. Company leadership must also adapt to retain that talent and ensure the success of their dev teams.

    The Bureau of Labor Statistics reported that a record 4.5 million Americans voluntarily left their jobs in November 2021—and in December 2021, CompTIA’s Tech Jobs Report showed that open job postings for tech and IT roles increased 53% year-over-year. With the need for tech and IT talent persisting in 2022, a combination of widespread burnout and technical skills gaps have made it even more difficult to find and retain top IT talent. 

    But that’s not the only challenge. The impact of remote work has triggered fundamental changes in the developer role, further compounded by tech companies’ increased migration to cloud infrastructure. And within organizations, a lack of foundational knowledge and formal company training is creating discrepancies in how development methodologies are being applied. 

    With developer expectations and skills evolving, Agile development methodology is more relevant than ever thanks to its adaptive nature and flexible, iterative processes. Company leadership must internalize this fact and put formal practices in place to standardize methodologies within their organizations. By doing so, leaders can arm developers with the tools they need to embrace rapidly changing development standards and methods—and retain top IT talent in a high-turnover marketplace. 

    Changing Developer Roles Bring new Possibilities and Challenges

    The pandemic profoundly accelerated the need for remote-based work structures, and with employees physically out of the office, many organizations began placing a much higher priority on their migrations to cloud-based infrastructure—both physical and organizational. This push placed a huge burden on development teams to move organizational and project data to Cloud infrastructure at faster-than-normal rates. For IT professionals, the pandemic-triggered disaster response has accelerated a permanent migration to the cloud as a way to safeguard access to digital infrastructure and processes. For developers specifically, this migration triggered many teams to embrace infrastructure-as-code (IaC). 

    IaC is a core DevOps practice that allows for infrastructure (like networks, cloud services and virtual machines) to be constructed and managed through code instead of manual processes.  This means that developers are increasingly writing the actual infrastructure their software runs on, which has game-changing advantages for automation, traceability and reliability—and impacts virtually all DevOps practices. With no one in the office to perform administrative and operational IT work, IaC is particularly useful. But since developers must have the necessary technical skills to write this infrastructure in addition to their traditional code, IaC has created a gray area where developers are also becoming IT operators and systems designers.

    The shift to IaC has evolved standards for developers, and it requires a higher level of flexibility within development teams and companies as a whole. Adopting IaC goes hand-in-hand with strengthening and refining Agile processes because creating standardized Agile practices enables not just greater agility, but also more accurate visibility—both necessary capabilities as staffing models evolve and the roles of developers and IT operators become more intertwined. But company leaders can position their development teams to succeed in this changing tech landscape and reap the benefits of increased collaboration and efficiency that IaC and cloud-based technologies provide. 

    3 Key Ways Leadership Can Support Development Teams

    The role of development teams is changing fast, and leaders must keep pace to retain IT talent and safeguard the health of their organizations. With that in mind, here are three ways you can support your development teams as they navigate changing development standards. 

    1. Standardize best practices. Even within a single organization or a single development methodology, go-to practices can vary among IT and development professionals. To successfully execute Agile, teams must have standardized best practices to ensure consistency in foundational knowledge. Agile’s iterative processes can lead to useful shorthand and improvisation, but only if developers are working from the same set of methodology standards and solid foundational knowledge. 
    2. Increase commitments to formalized training—especially for new hires. To fully benefit from Agile’s capabilities, all employees must have foundational knowledge of its processes—especially new hires. Provide formal education and training on industry-accepted Agile standards to eliminate skills gaps and cultivate institutional knowledge within your organization. Institutional knowledge ensures that quality standards are well-defined and achievable, ultimately strengthening the collaborative capabilities of your development teams. 
    3. Prioritize measures to decrease burnout. The pandemic shed light on burnout across industries, and the IT/tech world was no exception. It’s up to leadership to implement tangible measures aimed at reducing employee burnout—like managing realistic workloads, allowing for flexible working schedules and implementing policies that encourage work-life balance. Consistent standards lead to meaningful reporting, which ensures accurate measurement of team performance and workload.

    Preparing for Future Evolutions

    Remote work isn’t going anywhere, and companies that fail to embrace remote-based technologies risk employee flight and obsolescence. As development methodologies evolve to accommodate pandemic-triggered challenges and IT hiring gaps, the developer role will continue to change. In five to 10 years, it will look much different than how it looks today and companies must be willing to embrace these changes to ensure the success of their IT and development teams. 

    Agile development methodology was designed to adapt to rapid technological innovation and organizational change. The shift to remote work and the IaC revolution is the future—and it’s here. These forces are driving hybridized development methodologies that serve the new standards they impose. Embracing these changes is an organizational imperative, and by committing to standardized knowledge within your development teams, you can retain your top IT talent—and ensure your teams are poised and ready to meet these new challenges. 

  • Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian has added an extensible catalog for tracking software components, dubbed Compass, to its portfolio of DevOps tools along with an Atlassian Data Lake and Atlassian Analytics cloud service that makes it simpler to aggregate and query data collected from the company’s portfolio of tools.

    In addition, Atlassian is making its Atlas collaboration framework—formerly known as Team Central—formally available in beta. That framework, in effect, provides an overlay through which different collaboration tools adopted by various DevOps teams can be more easily integrated.

    Compass provides DevOps teams with the ability to map all the components they use to assemble their software as well as the teams that own them. DevOps teams can access shared components and documentation along with scorecards to allow them to measure and evaluate their architecture based on the baselines, security or compliance requirements they might be required to meet. It can be extended to other applications via an integrated Apps engine using Forge, the existing Atlassian cloud development environment.

    Tiffany To, head of product for Agile and DevOps at Atlassian, said Compass is designed for DevOps teams that are typically trying to manage 50 or more microservices. It is designed to be deployed alongside the Jira project management software that is widely used by software development teams to manage multiple projects.

    Atlassian Analytics, meanwhile, is based on a visualization and analytics platform the company gained last year with the acquisition of Chartio. Initially, the Atlassian Data Lake will include data from Jira Software and Jira Service Management tools with support for additional Atlassian platforms planned.

    Collectively, these tools are part of an ongoing Atlassian effort to make it simpler to integrate multiple DevOps teams, said To. Many of those teams prefer to maintain autonomy over the tools they select. The challenge that creates is organizations need some type of overlay through which they can collaborate and share best practices, she said.

    A survey of 2,000 developers conducted by Atlassian found half of the respondents exercise strong autonomy over the tools they use, with more control over tool selection gained as developers become more experienced. The same survey also found that 65% of developers felt they should be responsible for more of the software product life cycle than they currently are.

    It’s apparent that most organizations building software are trying to strike a balance between developer autonomy and centralized control. Developers are expensive to hire and retain, so there is a natural tendency to make available the tools they prefer. That, however, can lead to a level of tool sprawl that makes it difficult to determine the overall state of application development and deployment within an organization.

    Regardless of the approach, the need to remove as much friction as possible from DevOps workflows is clear, especially as the number of simultaneous application development projects continues to multiply. The challenge and the opportunity, of course, is achieving that goal while keeping developers happy.

  • FusionAuth Adds Support for ARM-Based Architecture

    FusionAuth Adds Support for ARM-Based Architecture

    Most developers need three things in life: Control, interesting projects and the ability to build on the technology of their choice. Now a new development promises to put all three in developers’ hands—FusionAuth’s announcement of its support for ARM-based architecture.

    FusionAuth solutions offer multi-factor authentication, passwordless authentication and single sign-on, among other features. ARM-based architectures offer simplicity with a lower and cooler energy footprint. Translated into DevSecOps benefits, this means that FusionAuth just made it significantly easier for developers to meet identity and authorization requirements and strengthen their security when building on ARM architecture.

    We talked to Daniel DeGroff, co-CTO at FusionAuth, to find out the details on how this support can benefit DevSecOps.

    The Movement to ARM-based Architecture

    You’ve probably noticed many forward-thinking developers are turning toward ARM-based technologies. Developers can count on interoperability across different implementations and different devices—and ARM processors offer a lower operating temperature and reduced power consumption. They’re also inexpensive to produce, making their price point attractive. This has earned them a place in everything from servers to smartphones to the world’s fastest supercomputer.

    With many developers spotting the potential for higher performance and cost savings, it’s no surprise that vendors like FusionAuth would move to support ARM-based infrastructure, as well. By working with ARM processors, the company can support additional use cases such as IoT and high-performance cloud platforms that are built on ARM-based architectures. DeGroff described it as a pragmatic—and inevitable—move, and said, “If you want to use these new machines, you have to support this architecture in some fashion.”

    “We develop on the Apple MacBook, and all new workstations will use Apple’s custom silicon which is based on the ARM architecture,” he pointed out. “ARM is generally faster and less expensive than an equivalent x86 server platform, and many of the low-power IoT devices will utilize the ARM architecture as well.”

    DevSecOps Benefits: Greater Flexibility, Easier Security

    FusionAuth’s ARM support can make the average security-minded dev’s life easier in several ways. FusionAuth runs on any platform, anywhere; by supporting ARM-based technologies, the company is extending developers’ ability to deploy its authentication and authorization platform how and where they want. “We have to ensure FusionAuth runs where our users want to develop,” DeGroff said.

    In helping developers build on ARM-based architecture, FusionAuth also makes it easier for them to use an API to bring in FusionAuth at the early stages of app or software development. One of the platform’s selling points is that it makes it simpler for developers to solve typical authentication obstacles, like weak password policies or difficulty with privileged access rules, DeGroff said. By supporting ARM-based technologies, FusionAuth aims to help developers successfully meet even tough security requirements through flexible, sophisticated identity authentication and access tools—and do so earlier in their development cycles.

    A Seamless Transition to Smarter Authentication

    If you’re a developer interested in exploring the combination of FusionAuth and ARM technologies, DeGroff said any transition will feel seamless. “There is a great business case for moving workloads to this architecture,” he points out. Developers who want to take advantage of the improved performance and lower costs can begin to migrate workloads to ARM-based platforms now.”

     

  • Google Allies With GitHub to Secure Software Supply Chains

    Google Allies With GitHub to Secure Software Supply Chains

    Google today revealed it has been working with GitHub to create a forgery-proof method for signing source code as part of an ongoing effort to better secure software supply chains.

    Bob Callaway, technology lead for open source software supply chain security at Google, said a prototype of this method, written in the Go programming language, generates non-forgeable provenance using GitHub Actions workflows for isolation and code signing tools for authenticity provided by Sigstore. Projects that make use of GitHub runners to run jobs can now achieve the third level of security as defined by the supply chain levels for software artifacts (SLSA) framework to assure software artifacts are authentic and trustworthy, he said.

    The reusable workflow also protects against possible interference from maintainers who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which prevents maintainers from altering information via variables, steps, services and defaults.

    The goal is not only to ensure the provenance of individual software artifacts but also make it possible to identify which build system was employed to create that artifact, said Callaway. In addition to working with GitHub, Callaway added that Google expects to apply this method to securing other build systems that organizations used to construct applications.

    Overall, Callaway said, Google is also working toward embedding security functions with DevOps platforms to ensure the integrity of software supply chains, in addition to educating developers on how to build more secure software.

    To protect against the possibility of one job tampering with artifacts used by another job, Google’s method creates a trusted channel. Job outputs send hashes that are then used to verify the binary received via the untrusted artifact registry. The OpenID Connect (OIDC) protocol, which GitHub just opted to support, is then used to prove the identity of the workflow to an external service, such as Sigstore, by attaching a unique JSON web token (JWT) to each runner. The token contains verifiable information about workflow identity such as the caller repository, commit hash, trigger and the current workflow path and reference.

    That makes it possible for the workflow to prove its identity to the  Fulcio root certificate authority provided by Sigstore. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner. A record of that signing is kept in Sigstore’s transparency log Rekor. Users can then rely on the signing certificates to verify provenance in a way that is authenticated and non-forgeable. That approach means maintainers don’t need to manage or distribute cryptographic keys for signing, which until now have made it challenging to manage code signing at scale, Callaway noted.

    In the wake of a series of high-profile security breaches involving open source software, Google and others have significantly increased the resources being applied to securing both open source and proprietary software within the context of a set of DevSecOps best practices. It may be a while before the benefits of that effort are pervasively employed by developers, but it’s clear that substantial progress is being made involving everything from the tools developers use to the build systems managed by DevOps teams.

  • Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    A survey of 140 enterprise architects and IT leaders published today suggested that, while moving applications to the cloud remains a priority, more attention is being paid to reducing technical debt by retiring applications.

    Conducted by LeanIX, a provider of a platform for managing enterprise architecture and managing value stream management (VSM), the survey found 40% of respondents identified reducing technical debt created by legacy applications and modernizing legacy systems as their top IT priorities. A full 96% said their company has at least one project planned for this year aimed at reducing technical debt with more than half (52%) noting that retiring IT applications is the primary means they will employ to reduce technical debt.

    Nearly 60% considered migrating applications to the cloud to be a high priority, as well. However, less than a quarter of respondents (24%) identified cloud initiatives as a top IT priority. The second most important cloud initiative, identified by 41% of respondents, is to increase the number of SaaS applications being employed.

    Regardless of the approach to the cloud, nearly three-quarters (73%) of respondents said enterprise architects should form a closer connection with software development teams, with an almost equal percentage agreeing on the importance of tracking the business impact of software development.

    However, only 16% of those surveyed considered the evolution and improvement of their security posture a top priority, even though more than two-thirds considered security initiatives—such as improving risk assessment capabilities and adopting more zero-trust IT offerings—as important or highly important.

    Dominik Rose, vice president of product management for LeanIX, said enterprise architects—or someone within IT who assumes responsibility for enterprise architecture—are trying to minimize disruptions to the business as IT environments continue to expand and evolve. The challenge they encounter is there is usually a divide between software development teams and the rest of the business. The size of that divide will vary by organization; in general, though, digital business transformation initiatives should help bridge the gap—assuming enterprise architects can establish and maintain close connections with software development teams, noted Rose.

    LeanIX is making a case for an enterprise architecture management (EAM) platform that provides visibility into IT environments. The company also makes a VSM offering available on top of that platform that provides visibility into software delivery processes. The number of organizations that have adopted VSM platforms remains relatively small, but as organizations depend more on software to drive digital processes, the need for senior business and IT leaders to have more visibility into software delivery schedules is expected to increase.

    In the meantime, it remains to be seen just how aligned DevOps teams are with the strategic goals of the business. The ability to build and deploy software faster does not automatically equate to gaining a deeper understanding of the needs of the business. In fact, there may come a day when software is built and deployed faster than most organizations can effectively absorb unless they have some equivalent of a VSM platform in place.

  • Overcoming IT Complexity With Full-Stack Observability

    Overcoming IT Complexity With Full-Stack Observability

    Organizations embarking on digital transformation journeys tend to develop complex infrastructures. They update their legacy applications while adding multi-cloud, virtual and cloud-native capabilities. Eventually, IT pros find themselves managing diverse, complex and distributed networks including cloud, system, application and database infrastructures.

    To rein in the resulting complexity, organizations tend to amass monitoring and managing tools. The goal is to simplify systems oversight—but instead, silos tend to develop because teams use a wide variety of tools to manage their networks or infrastructures. 

    This piecemeal approach worsens operational blind spots and delays problem resolution. It also increases security exposures. Soon, overwhelmed IT pros can’t keep pace with app modernization or infrastructure dynamics because they’re awash in complexity.

    Though this scenario is common, it’s not inevitable. IT teams can ease their digital transformation journey by implementing an integrated and cost-effective full-stack, end-to-end monitoring service capable of overcoming complexity and silos. 

    Organizations require full-stack observability.

    How Observability Differs From Traditional Monitoring

    Observability goes beyond traditional monitoring. Traditional monitoring helps IT organizations understand the actual state of their infrastructure and applications. It captures and processes volumes of infrastructure and application telemetry data and notifications and displays which components are up, which ones are down and which ones have changed. 

    Usually, traditional monitoring focuses on a specific network, cloud or infrastructure. It tracks application and infrastructure elements so IT pros can identify anomalies and investigate problems as they arise.

    Monitoring relies on metrics-oriented dashboards built to assess telemetry data against manual or basic statistically relevant thresholds. Monitoring tools are invaluable, but they don’t offer cross-domain correlation, service delivery insight, operational dependencies, or predictability. Modern systems have complex multi-cloud environments and a deluge of telemetry data: This counts as a shortfall.

    Observability does more. It measures the internal states of systems by examining the outputs and looks at applications and systems in their entirety—from the end-user experience to server-side metrics and logs.

    But observability also includes monitoring as a critical element. To gain observability, you must first collect information through monitoring. Observability uses the insights and metrics generated through monitoring to understand what’s causing the issue at hand. 

    Monitoring aggregates and displays the data to determine whether the systems are operating as expected. The analysis of this information is compared with expected outcomes and objectives. This allows IT pros to understand the state of their infrastructure and applications. 

    Silos are thus avoided because complex environments are viewed in their entirety.

    Observability in Action

    Once in place, observability allows IT organizations to continuously improve performance, availability and digital experience across complex, diverse and distributed hybrid and cloud environments.

    With observability, organizations can quickly find and resolve anomalies. However, full-stack observability goes beyond monitoring and expedited problem resolution: It supplies insights, automated analytics and actionable intelligence through cross-domain data correlation, machine learning (ML) and artificial intelligence for IT operations (AIOps). It works across massive real-time and historical metrics, logs and trace data.

    Observability goes beyond the silos and the piecemeal approach associated with traditional monitoring. And when observability isn’t limited—when it includes ML and AIOps—it uses the large volume of gathered data and supplies insights, automated analytics and actionable intelligence to help IT staff expedite problem resolution. It also enables ITOps, DevOps and security organizations to achieve consistent, optimized and predictable business service delivery with continuously improved digital experience and IT productivity. 

    The result is customers and employees benefit from better-run systems. The technology provides organizations of all sizes and industries with comprehensive, integrated, and cost-effective functionality through cloud-connected on-premises or software as a service (SaaS) deployment flexibility.

    When embarking on digital transformation journeys, organizations don’t need further complexity—certainly not while they update legacy applications and add a plethora of modern services and capabilities to their stack. The key to reducing complexity is observability.

    Observability simplifies the transformation process. It reduces operational noise to benefit ITOps, DevOps and security teams. They can become more proactive in issue and anomaly detection to achieve optimum IT performance, compliance, and resilience. With full-stack observability, any organization—no matter its size or industry—can reduce IT complexity while readying itself for digital transformation.