devopsy.kinsta.cloud

Tag: containers

  • What We Don’t Know is Dangerous

    What We Don’t Know is Dangerous

    Pop quiz: How many database management systems (be they RDBMS or NoSQL or even flat file) do you have running in your overall organization? Not actual databases, but management systems?

    How many containers do you have that are exposed to the internet, directly or indirectly? Not container management systems, because you’re only running a couple of those and they’re all relatively new, but actual containers?

    The questions could go on and on. Not too long ago, because there was an identifiable cost associated with it, cloud inventory management became a popular thing – finding and removing cloud instances, services and storage that were no longer necessary became a part of normal operations for organizations that had even a mid-sized cloud presence.

    But now, we have sprawl all over the place. So let’s extend inventory management to all software, and get rid of what isn’t needed on a regular basis … because it does indeed build up quickly.

    Yes, there are a few companies out there trying to do just this, and I encourage you to check them out. I have not, because our inventory at Ingrained Tech is manageable without that level of overhead. Our development and ops time is limited, so we keep a tight rein on what is out there and the maintenance it requires.

    But for larger organizations, the more you have out there, the larger attack surface and potential data sieves you have in place. So make sure if it isn’t needed, it’s gone. In the age of containers, this actually requires a fair amount of investigation; first, a list of all containers part of an ongoing project (and in even a mid-sized company, “They’re all together for each app,” won’t create this list because random containers are out there, too). And then a list of all containers not associated with a known project that can be gone through and usage determined.

    It’s not glamorous. It’s a bit of a slog. It’s in the organization’s best interests, though, and the slog should motivate your teams to put a policy in place to manage container life cycles. Like notes in Docker files that say when the container is no longer needed, or what it is needed for, so future you can easily get rid of it without stress.

    If you are in a containerized environment, this problem is growing almost by the day. Seriously. On our last project, we had 12 active containers before we pared it down to the five we needed long-term. The others were R&D along the way or tools we were using before focusing on a different method of achieving the same goals. Since we’re a small team, we just cleaned up when the project was coming into focus, but a larger org needs to be more focused on cleaning things up as they go.

    Meanwhile, those assets are letting customers get to your org, and allowing employees to manage the systems. Keep rocking it, and just remember to pick up, particularly after cutting-edge new projects, but also occasionally as just a normal cleanup step.

  • DevOps and Containers

    DevOps and Containers

    “Works on my machine!”

    We’ve all had that co-worker. I have had one at pretty much every company I’ve worked for. At several jobs, it devolved into a running joke.

    There is a belief that containers alleviate this issue. And they may—or they may simply mask the issue. The choice is up to IT.

    Inevitably, something that works on one machine and not another can be traced back to on-the-fly configuration changes. If “we use containers for DevOps” means that developers have full control of the container environment, then it must also mean that any configuration changes be codified into a documented container image that can be spun up repeatedly and even recreated in a Dockerfile if needed.

    If, instead, it means that devs have a playground in containers and, once they get it going, they can chuck it into production—even if you don’t say it that bluntly—then you are making things worse with containers, not better. At least in the days of “works on my machine,” the issues had to be resolved because the only time you heard that phrase was if something didn’t work on the machines it needed to be deployed to!

    As a developer, it is tempting in both container and virtual environments to upgrade a package or tweak a setting without documenting it. But a clean DevOps environment needs to be able to build the product from Dockerfiles, not from a pre-existing image. Yes, you can just clone the existing image, but then there is no documentation of what has actually been changed and it takes a lot more work for those following you and debugging future problems.

    So take the time; keep an up-to-date Dockerfile (or whatever equivalent script is used to build your containers). It is not that significant an investment to stop for a minute, open a file and type a few lines. And it pays off in spades if, in the future, someone is trying to figure out what the heck is going on in there. Consider it self-documenting configuration. I’m not a fan of “self-documenting code,” but for config, it is pretty clear if you go, “Oh, we needed version 10.2, not version 10.1; let me update the init script.”

    There are a fair number of shops out there that modify things running in production, and the world hasn’t ended yet—though that may well be how it happens. So, a good practice that will help those trying to follow behind you is clearly not a necessity. But each of us has gone back after a year and said, “Why did we do that this way?” which was (or wasn’t) then answered with, “Oh, here is exactly how the environment was configured.” But it might help answer the ‘why.’

    Your apps are powering the world—or your specific apps are powering your little piece of it. And you’re kicking it just keeping them running. Now, go make them better! Consolidate changes, manage configuration through Dockerfiles, Ansible, init-scripts, whatever combination you use … And keep rocking.

  • Building a Reliable App Installation Experience With MSIX

    Building a Reliable App Installation Experience With MSIX

    Simple, safe, reliable software installs and uninstalls are always best, but getting there isn’t easy. Applications break each other—or even the operating system itself.

    MSIX, Microsoft’s packaging format, is the newest replacement for the decades-old Microsoft Software Installer (MSI) and setup exe installer technologies. MSIX is gaining acceptance and wider adoption because of the benefits it delivers: security, ease of use and reliability in application installations. 

    MSIX provides a new, modern runtime environment intended to protect both your application(s) and end user systems. Enterprise users prefer the MSIX format because it provides the most appropriate framework to modernize applications; simultaneously reducing IT departments’ workloads when preparing application package(s) for delivery to hundreds or thousands of end users.

    As developers who build Windows desktop applications embrace the concept of running code in an MSIX container, understanding certain key concepts can streamline and strengthen their application installation experience.

    Why MSIX?

    Running code in an MSIX container can solve common problems encountered by developers coming from non-containerized deployments. This includes products built and delivered as a Win32, .Net Framework or Universal Windows Platform (UWP) packages—or when starting a new project from scratch. 

    In addition to providing clean installation and uninstall processes, MSIX enables enterprise customization in independent packages via modification packages. It also supports the ability to deploy applications through enterprise tools (e.g., Microsoft Endpoint manager) or to the cloud (Azure Virtual Desktop, MSIX app attach).

    Value for Developers and IT Pros

    MSIX improves upon the more restrictive model of UWP while still running in a container. It allows developers to code in their preferred way (e.g., unmanaged code using Windows Forms, calling the Win32APIs or managed code using XAML and .NET framework versions of the APIs). 

    Some tactics must be changed to run inside the MSIX container, however. In addition to minimizing work, it facilitates building modern IT ecosystems, deploying apps and updates faster and more frequently and modernizing applications into the new world of containerized packages.

    MSIX also supports deploying applications via enterprise tools (e.g., Microsoft Endpoint Manager) or even to the cloud.

    Value for Users

    By delivering a more streamlined installation experience for users, MSIX offers benefits to customer and end users, including: 

    • Guaranteed clean installs: This prevents time wasted on installs, uninstalls, reinstalls or issues that occur with other installed applications.
    • Isolation between applications except when isolation isn’t desired.
    • Greater security to protect the customer and the application.
    • Improved features including automatic updates, differential updates and disk space optimization—without having to customize code or the packaging process.
    • Single-instance storage; automatic block-level deduplication for any file in any installed package.
    • Fewer support calls: This cuts down on annoyances, delays and expenses for all involved.

    Elements of a Successful MSIX Project

    MSIX projects require a different approach than what many developers are accustomed to. To provide customers with the best package file(s) possible, consider the following elements as part of the project. Doing so will strengthen additional project activities, project setup, testing and debugging and supported schemas.

    1. Digital signing: Secure installations of MSIX packages are provided by installing the application to the app container and enforcing the app packages with digital signatures (with a valid code signing certificate). Only trusted apps are installed, enforcing the integrity of the package and its container after deployment.
    2. Package components: An MSIX package includes files that are essentially a set of ingredients—some generated directly (e.g., image files for the start menu) and some created as part of the build process (e.g., output by other vendor tooling). Ingredient files—including root and virtual file system (VFS) folders—will be passed to the MakeAppX command to generate the package.
    3. An efficient MSIX build process: Custom modifications are sometimes needed for a package, such as when PSF is appropriate for handling a few unexpected scenarios; this requires repackaging extracted contents back into the MSIX package. Whether or not such modifications are required, an efficient build process is always necessary. Building an MSIX/APPX package manually is possible without any packaging tools, with documentation provided by Microsoft. Alternatively, tools such as InstallShield can automate the process.
    4. MSIX bundles: .msixbundle installation ensures that only packages applicable to a device’s architecture are installed. An MSIX bundle targets different system architectures, language-specific assets, varying image-scale assets or resources applicable to specific devices.
    5. Modification packages: MSIX supports the creation of modification packages intended to modify or extend existing packages. These allow customers to create customized configurations for your package or enclose a plug-in.
    6. Shared package containers: When working closely with two separate packages, each with its own start menu and other entry points, a shared package container may be appropriate. This additional XML file may be installed on the end user’s computer to tell the OS that the packages should share a single container rather than be isolated from one another.
    7. AppInstaller (XML) file: While MSIX and bundle files are generally directly installed into the operating system, the OS facilitates installation and management of updates automatically. Microsoft now makes this functionality available for packages delivered externally by using an AppInstaller XML file to perform the installation, telling the OS where to find the current msix file, where to look for updated AppInstaller files and the configuration of updated settings for the package.
    8. MSIX core: MSIX Core is built for older Windows versions that don’t natively support MSIX. This enables installation of MSIX apps on previous versions of Windows (as long as the apps are built to work on those versions of Windows).
    9. Basic AppXManifest structure: Last but not least, the most important file in an MSIX package is the AppXManifest file, an XML file that defines how the application will integrate with the OS for access by the end user, including the application model used that impacts runtime container features. Understanding the structure and element tags (package, properties, resources, dependency capabilities, applications/application element tags) of the AppXManifest early on will help ensure appropriate project setup.

    While MSIX continues to evolve, so can your projects. The end results will be application packages that not only streamline work for IT departments but also reduce headaches for end users.

  • IT Ops Trends: Cloud, Containers and COVID

    IT Ops Trends: Cloud, Containers and COVID

    Almost all companies are modernizing their IT infrastructure to remain competitive, with the focus firmly on migration to the cloud and the use of dynamic infrastructures. In a recent Trends in IT Ops 2021 survey, more than 160 IT professionals were asked how the implementation of IT strategies affected their day-to-day work. The results provided an impressive insight into the current work priorities of system administrators and IT Ops in general.

    According to the survey, most administrators believe that monitoring cloud (79%) and container (73%) environments will take on a more important, or much more important role for them in the future. Additionally, 59% of those surveyed agree that their job role has evolved over the years due to cloud computing and containerization.

    Not all IT Teams are Equal

    However, the data also shows that the changes are not affecting every IT team equally. For example, 37% of all respondents say that cloud solutions are not relevant—or less relevant to them on a day-to-day basis. This response shows that on the one hand, system administrators see cloud computing as an essential topic. However, on the other, the impact in practice is not felt to the same extent by every administrator. These responses show that not every administrator has to deal with cloud platforms on a day-to-day basis, with some being ‘siloed’ into dedicated teams that may not interact with the broader corporate cloud strategy. In addition, not every organization has fully committed to the cloud, with some finding their migration hindered by applications that are not suited to cloud migration.

    In the survey, 45% of respondents also said they believe the importance of monitoring physical infrastructure will not change in the next few years. However, 43% believe that monitoring physical systems will become more important or much more important. Conversely, a mere 1% replied that they thought physical infrastructure monitoring was less critical. 

    Taken together, these responses demonstrate that, despite the excitement around the cloud, many organizations take a hybrid approach to infrastructure. IT Ops and administrators recognize the importance of monitoring cloud systems and dynamic assets while, at the same time, the monitoring of local systems remains relevant or is even expected to gain in relevance.

    Network Management and Automation

    Cloud and containers enable faster growth of IT environments and promote digitalization. However, they also lead to a sharp increase in data traffic and more complex networking of systems. As a result of these changes, the demands on local networks are growing. This increasing demand demonstrates the importance of network management tools. 81% of respondents said that solutions in this area are relevant, or very relevant to them in their day-to-day work.

    This year, the move to a home office joined the trend towards migration to the cloud, containers, and network monitoring. In the wake of the COVID-19 pandemic, many IT departments had to adapt their infrastructure to allow employees to work from home offices. However, most administrators were relatively stress-free, with 54% saying they had no trouble adapting infrastructure to meet remote work requirements.

    Automation is also a key issue. For example, 81% of all respondents say projects that deliver deployment and configuration automation have been relevant in their organizations in the past 12 months. In addition, 92% say that automation tools are relevant, or very relevant to them on a day-to-day basis. 

    Cloud, Containers and COVID

    The Trends in IT Ops 2021 survey shows that system administrators are concerned with cloud computing and containers and several other topics. In addition, most administrators recognize the increasing importance of monitoring cloud environments and containers. That said, administrators continue to see monitoring networks and other physical infrastructure assets as critical, and some system administrators see increasing importance in monitoring this vital area. 

    In addition to the topics outlined here, respondents also provided feedback on topics such as virtualization, application performance monitoring and network management.

  • Extending GitOps to the Enterprise

    Extending GitOps to the Enterprise

    GitOps is a relatively new term, but it continues to gain momentum as more organizations embrace the paradigm. In DevOps, GitOps lands on the software engineering side of the development and operations continuum. Even though GitOps is more likely to be adopted by smaller organizations, larger enterprises can successfully implement GitOps with just a few tweaks to the overarching framework.

    Let’s start at the beginning. Wouldn’t it be great if we could combine DevOps and GitOps approaches and use the Git distributed version control system as the ultimate source of truth? Then, when there’s a dispute over the correct state, people know where to go for the correct version.


     

    In GitOps, the system’s desired configuration is stored in a revision control system such as Git. Any difference between the desired state stored in Git and the system’s actual state indicates to DevOps teams that not all changes have been deployed. These changes can be reviewed and approved through standard revision control processes such as pull requests (PRs). When a PR is approved and merged to the main branch, an operator software process is responsible for changing the system’s current state to the desired state based on the configuration in Git.

    GitOps doesn’t require a particular set of tools, but the tools must:

    1. Operate according to the desired system state stored in Git.
    2. Detect differences between the desired and actual states.
    3. Perform required operations on the infrastructure to synchronize the actual and desired states. 

    In an ideal implementation of GitOps, manual changes to the system are not permitted and all changes to configuration must be made to files stored in Git. The infrastructure and operations engineers’ roles in a GitOps model shift from performing infrastructure changes and application deployments to developing and maintaining GitOps automation and helping teams review and approve changes through Git. 

    GitOps is great for non-critical environments, but enterprises are less likely to adopt GitOps due to a number of challenges facing GitOps users.

    Challenges with GitOps

    GitOps is applicable only to a subset of the software development life cycle (SDLC). This is important because GitOps tools are sometimes marketed as a one-size-fits-all solution that will solve all release problems—this is simply not true. First, GitOps requires that your deployment artifacts are already there. This means that tasks such as

    • Compiling code
    • Running unit/integration tests
    • Security scanning
    • Static analysis

    are not a concern of GitOps tools and are assumed to already be in place. GitOps also doesn’t address promotion of releases between environments.

    Auditability

    A default GitOps process is not fully auditable because of force push. Force push essentially allows users to remove any unwanted blocks of commits from Git history on the central repository.

    Business Approvals

    PRs are a typical approval model used in GitOps. Developers make changes, create PRs and then an approver may accept that PR. This would be recorded and a change would be deployed. A PR-based approval model assumes peers are already using Git and are familiar with PRs. 

    Generally this works great until we need to include business approvals. Business personnel may not be familiar with Git or PRs. If a team needs business approvals, they have to build a process on top of GitOps. This drastically increases lead time. 

    Governance 

    GitOps is dependent on a pure PR-approval based model, one in which the PR approver is responsible for reviews. After a PR is approved, there is no way to enforce enterprise policy rules. Enterprises need to control what end users can do on specific clusters to ensure those clusters are in compliance with policies to meet governance, legal requirements or enforce best practices.

    An Enterprise Approach to GitOps

    However, there are ways to solve this problem at the enterprise level.

    Alerting on Drift Detection 

    Enterprise customers get alerted whenever there is a drift in their repository and, based on that, customers can choose to approve or reject the drift. If rejected, the merged PR should be reverted to the previous state to ensure that Git is in sync with the desired state of the cluster.

    Use a Pipeline for Promotion of Releases Between Environments

    To promote an artifact between environments, users would have the ability to use a pipeline with deployment stages, performance monitoring and log analysis/approvals. 


     

    Let’s say the developer commits the source code and the GitOps deployment happens in the QA environment. The PR can be automatically approved upon meeting the policy standards set by the company. Then it can be pushed to a production environment.

    Governance 

    There are many reasons why developers and platform engineers integrate policy-as-code into their current GitOps processes. For one, this strategy helps to accelerate application development and deployment because it helps solve many of the change management hurdles that slow development pipelines.

    On the development side, policy-as-code helps app developers understand and abide by the company’s configuration, security and compliance policies. For example, a developer may not remember—or may have no reason to know—when deploying a load balancer onto Kubernetes in AWS is or is not sanctioned. Policy-as-code solves this problem automatically.

    The ability to run policies during GitOps deployments and adhere to those policies as a part of the deployment and upon any violations—alert, audit, notify and automatically roll back the changes from Git to the previous successful compliant state so that Git remains in sync with the cluster.

    GitOps + AIOps

    There is a notion that once GitOps is in place, everything will work seamlessly with no problems. Not so much; it is important to continually monitor deployment state to ensure everything stays as it should. That is where AIOps comes into picture.

    GitOps enables DevOps and development teams to see any manifest change, infrastructure change or artifact change. Post-deployment, the GitOps operator can instantly understand the changes in the service health, see what caused those changes and automate the process of investigating them using AIOps. If any severe anomalies are found, the operator can determine the current state of the system and, should anything differ, revert to the previous compliant Git commit. 

  • 4 Container Orchestration Security Concerns

    4 Container Orchestration Security Concerns

    Container orchestration is a must-have technical skill, according to 51% of respondents to the 2021 Upskilling survey from DevOps Institute. So, it’s no surprise, then, that container technology is becoming increasingly popular. However, container environments are far more complex and dynamic than other infrastructure, making container security essential. Security ensures containers are running as intended, protecting the infrastructure, software supply chain, runtime and everything in between. 

    If you’re looking to use container-based applications within your software infrastructure, you may want to keep in mind the security risks that come with this technology. To help, I asked DevOps Institute Ambassadors to weigh in on the security concerns they have with container orchestration. Here’s what they shared: 

    Anshul Lalit, head of technology and transformation, Kongsberg Digital

    “One of the most common security concerns with container orchestration is that it shares the host operating system and the host kernel. Thus, it raises the concern that a host OS or kernel vulnerability could potentially be taken advantage of and exploited in a container. An example of this is the recent attacks on Linux’s mmap syscall. Though you can avoid this by using defined best practices, it’s worth noting that any compromise in the host OS could compromise containers in that host. This scenario is in contrast to a virtual machine (VM), in which the guest OS and the host OS and kernel share no common binaries and are thus inherently separated.

    Similarly, a rogue process, a vulnerable container image that is running, and a security vulnerability in the orchestrator can all provide an attacker a means to get their foot in the door. For example, if a container is designed to run with root privileges, an attacker running a vulnerability scanner on the orchestration host will quickly find the vulnerable container.

    Users should follow best practices for securing the containers running in a container orchestration platform by providing a Linux security module, for example, that can enforce a policy that will protect against a rogue container or user from extracting sensitive data from the host system.”

    Supratip Banerjee, solutions architect, Principal Global Services

    “Containers are creating new challenges for cloud security. While these structures are dynamic and automated, new threat vectors are also present for precisely the same reasons containers are useful. DevOps and SecOps teams must be aware and prepared for these possible issues:

    • Containers, unlike virtual machines, share the host operating system on which they execute. If settings are not correctly maintained, the host and containers may be exposed to security concerns.
    • Orchestration automation adds a degree of complexity which can lead to misconfigurations that overprovision access and, as a result, an expanded attack surface.
    • Containers are constructed using pictures kept in public or private repositories; they are frequently reliant on other images, and a single flaw in any of them might spread across thousands of containers.
    • Because containers are ephemeral, IP address-based security measures are ineffective and complicate forensic investigations.”

    Parveen Arora, co-founder and director, VVnT SeQuor

    “If your project(s) involves the use of containers, you will have decomposed your application into its various constituent services, which, while beneficial, isn’t necessarily as secure as if you are using VMs. Since container platforms like Docker borrow code libraries from the host, they’re fundamentally not as secure as VMs. Vulnerabilities in a container environment can therefore allow malicious software to break out of a container and infect the host environment.”

    Vishnu Vasudevan, head of product engineering and development, Opsera

    “The security challenge, especially when it comes to container orchestration, is people think they can spin up their own image or they can download the image from the cloud and start using it. It’s not as easy as everybody thinks. There are vulnerabilities being introduced every minute. You need to have a security tool and processes that can automatically scan for every container that is being splintered. Furthermore, a team needs to create shared practices around blue-green deployments or rollbacks of the container changes that are being pushed into production. 

    From the pandemic alone, we have seen significant cloud movement, but on average, 50 vulnerabilities are introduced every day. In fact, there are people just waiting for loopholes where they can execute malicious scripts. And some people, especially people who are in mining, try to gain visibility into vulnerabilities within cloud accounts and penetrate them to run huge containers for their own cloud mining purposes. On average, it can take 280 days to even detect any vulnerabilities or a hack into the system. 

    Companies using containers must consider threat vulnerability management as part of their orchestration strategy. Do you think the team is experienced enough to scan 50 vulnerabilities a day and fix them? Probably not, since release velocity is shortening a release cycle to one or two weeks for modern application initiatives. This creates a lot of technical debt that can accumulate rapidly, which is why threat vulnerability tactics and processes must be considered when moving to the cloud.”

    Learn more about container orchestration and similar topics by registering for an upcoming SKILup Day. 

  • …And all Those Other DevOps Tools

    …And all Those Other DevOps Tools

    When we started going through the DevOps toolchain for our new project, we found a ton of bits that normally we (and most likely you) wouldn’t pay too much attention to, because they don’t matter—until they do. Then we all pay attention. That’s why we added them to the toolchain list of options before they became a problem.

    It is time to stop, take a look around, make sure you have an inventory of what tools are going into the process of making your secret sauce. The easy one is IDE. For the last little while—say, a decade—we’ve let this largely be a team or an individual decision, but the steps required to do things and the add-ons/libraries used make this less and less about individual choice and more of at least a team, often an organizational decision. We’re doing it at the project level, so functionally equivalent to team. Our Java/Spring app is done in Eclipse because most of you are doing the same for that architecture. But our new Godot project will be in the built-in Godot editor (for Godot Script) and VS Code for C#. Again, because that’s all the rage in several languages, including C#.

    Here is the thing though – if you are using VS Code, you should keep a detailed and current list of plug-ins. I’m not a fan of their whole extension installing methodology through the command palette and want to make sure everyone has the tools needed at hand. In an enterprise setting, the ROI is there to just set it up and distribute to developers what they need in a package. But this is only a real possibility if most developers are on the same platform.

    What Git Desktop client is in use? While all of them support Git command line in the same format, helping each other use the UI for different operations kind of begs for standardization. Our team doesn’t change much, so I’m not terribly worried about this particular issue. We’re officially using GitHub Desktop, but as long as I’m not doing tech support (because you have a tool that you can’t use well), I don’t care if people stick to it. You might care more about that than we do—in this regard, we’re more like a startup than an enterprise. Since they share a command line, we can afford not to care. If you, as an enterprise, are providing ready-to-code environments, that is a different story.

    A couple of years ago we would have had to worry about containers, but these days we’re okay saying Docker locally and Kubernetes for production. While the Godot app doesn’t have a server component (hence the reason we’re keeping the Java/Spring app around), the build environment will be containers because we want to be able to build wherever we need to.

    Keep rocking it. I just thought I’d drop a list of what we’re going over—there is more, of course; this bit was focused on the developer tools side of things. I’ll eventually update with the final full stack, but for now, this bit is being put on the back burner while I look at some other areas. ::waves at security peeps::

  • Cosmonic Contributes WebAssembly Runtime to CNCF

    Cosmonic Contributes WebAssembly Runtime to CNCF

    Cosmonic today revealed it has donated its universal application runtime for building cloud-native applications using the WebAssembly (Wasm) development framework to the Cloud Native Computing Foundation (CNCF).

    The Cosmonic wasmCloud runtime makes it possible to run applications built using WebAssembly on any platform. In comparison, applications built using containers are not as portable because IT teams can’t take a container application developed for Linux and run it on Windows. The container technologies for each operating system are implemented differently.

    The CNCF will make wasmCloud available as a sandbox project and will invite other organizations to start making contributions as part of an effort to eventually put wasmCloud on par with other projects such as Kubernetes. There are already nearly 80 contributors to a wasmCloud runtime that was launched last November.

    Cosmonic

    The CNCF is trying to advance other WebAssembly technologies including Krustlet, a tool for Kubernetes environments that listens for event streams from new pods so that the scheduler can then assign workloads.

    However, the CNCF is now not the only organization looking to promote adoption of WebAssembly technologies. The Bytecode Alliance has launched WebAssembly (Wasm) and WebAssembly System Interface (WASI) initiatives as part of an effort to promote standards that would make it easier to run Wasm applications anywhere. Originally founded by Fastly, Intel, Mozilla and Microsoft, the Bytecode Alliance now also includes Arm, DFINITY Foundation, Embark Studios, Google, Shopify and University of California at San Diego.

    At its core, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment. That approach might one day replace the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct security boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application.

    Liam Randall, CEO of Cosmonic, said even though Wasm, in effect, provides another type of virtualization for applications, IT teams should not view it as a set of technologies that will one day obviate the need for containers. Applications developed using Wasm will be layered on top of various container platforms, he said.

    There is, for example, already a Wasm project that creates a server-side Wasm runtime that enables applications to be deployed on a secure container architecture that is more efficient than Docker containers.

    The World Wide Web Consortium (W3C) drove the development of Wasm as part of an effort to create a common format for browsers executing JavaScript code. Wasm is now being extended beyond browsers and JavaScript to enable developers to ultimately create a set of universal binaries that could work on any platform without modification.

    It may be a while before the fruits of those labors are realized. However, it’s apparent the walls that have separated one IT platform from another are starting to crumble. Once applications become much more portable, the reasons why one organization may choose one platform over another will have a lot less to do with what developers prefer.

  • Infrastructure-as-Code Security will Improve Your Cloud Security

    Infrastructure-as-Code Security will Improve Your Cloud Security

    Moving to the cloud creates a tremendous opportunity to get security right and reduce the risk of a data breach. Most organizations start their cloud security efforts by ‘shifting security left’ thereby addressing issues in the CI/CD pipeline. Fixing known vulnerabilities and risky configurations before pushing images to production makes sense. But there is an opportunity to shift security even further left—as you set up your cloud infrastructure—to reduce risk. Infrastructure-as-code (IaC) security allows you to define security controls as you configure your cloud infrastructure.

    Getting Started on Your Cloud Journey

    Before we dive into IaC security, let’s talk about why platform teams want to deploy infrastructure-as-code as they move through their cloud journey. Most organizations have not yet tackled IaC. They start their journey by experimenting with cloud configurations until they have defined a stack that works for their teams. In this early stage, application teams may be defining their own cloud stacks. They are manually configuring infrastructure or using scripts. Configurations may not be standardized across teams.

    Standardization of Infrastructure Saves Time

    Although experimentation is reasonable early on in the journey, standardization of infrastructure saves time. Cloud services are no different than applications that run on premises. When your teams are using different versions of tools in their stack, getting an application up and running can be a nightmare. Interoperability between services is challenging, and it can feel like you are fixing a different flavor of the same problem over and over.

    Mature cloud platform teams typically prefer to create a ‘golden image’ with a baseline set of services for development teams. They may create a menu of a few standard options to meet different teams’ needs. Because they are standardized, the platform team can take time to validate that they interoperate and are secure. For example, these golden images will be regularly scanned for vulnerabilities and updated to ensure they meet internal security standards and any relevant regulatory requirements.

    IaC security cloud

    Automating Infrastructure Deployment Reduces Errors

    Manually configuring the environment in the cloud for each team is tedious. Once these configurations have been standardized, the cloud infrastructure can be provisioned as code using templates. A declarative approach defines the desired end state, whereas an imperative approach defines the detailed steps to achieve the end state. The templates are normally stored in a Git repository and version controlled. Automating the configuration of infrastructure not only saves time but also reduces errors that can disrupt operations.

    IaC Security Shifts Security Further Left

    Once you have templates that define your infrastructure, standardizing permissions and access rights for services-as-code is a logical next step. The security team typically defines the guardrails or policies for accessing cloud services. These policies can then be defined as code along with the infrastructure configurations. This IaC security is a further ‘shift left’, allowing security to be embedded into infrastructure, even before an application can be deployed. Implementing policy-as-code minimizes the opportunity for human error in configuring security services. By defining these policies and enforcement guidelines together, the DevOps and security teams can establish a trusted partnership.

    Although some organizations may start their journey by implementing IaC security, for most organizations it happens later in the cloud journey. The order is less important than ensuring you take a DevSecOps approach and embed security at each stage to manage risk. Be sure to address the following areas as part of your cloud and container security program:

    Continuously Check Cloud Permissions and Configurations

    Even if you have IaC templates, you need a program to regularly take inventory of all cloud assets and confirm permissions and configurations. The Center for Internet Security (CIS) benchmarks are commonly used to check passwords and access rights. Beyond enforcing these best practices for security on cloud services, continuously checking for changes to permissions and suspicious activity is critical. The cloud vendors capture logs across all of their services, and your security tool should continually monitor and alert using those logs.

    Scan Images for Vulnerabilities and Risky Configurations

    Scanning for vulnerabilities and ensuring configurations use best practices allows you to shift security left into the development pipeline. Scan everywhere you have images—including within registries, pipelines and also check for new vulnerabilities identified for images running in production. Be sure to scan hosts as well as containers. Defining scanning policies and enforcing through the development process creates guardrails for the development team and clarifies expectations. Most regulatory compliance standards have image scanning requirements as well.

    Detect Threats and Respond to Alerts

    Prevention is fundamental but must be supplemented with threat detection and response. Alerting on unexpected behavior can identify the presence of a threat. Initially, teams may use out-of-the-box detection rules as a way to get started and then customize rules over time. Checking configs against dockerfile best practices is a good way to get started. Overly permissive access rights for containers is common in Kubernetes environments and should be allowed only when required.

    As your team develops more expertise with containers and Kubernetes, you can also implement zero-trust network security policies to block unexpected communication between pods, services and applications.

    Some DevOps teams handle triage of alerts, as they can quickly determine if the issue is a configuration issue or an indicator of compromise. Teams often map detection rules to the MITRE ATT&CK framework, allowing their security teams to manage alerts consistently across their environment. For any team to effectively respond to a security alert, it is important to capture a detailed record of exactly what happened before, during and after that event. This visibility can be particularly challenging with containers but it is critical because containers have short lives. The 2021 Sysdig Container Security and Usage Report revealed that about half of containers live less than five minutes.

    Complying with Regulatory Standards

    Complying with regulatory standards can be painful. Some standards were written with cloud computing in mind, like NIST 800-53 and SOC2, and others were not. With those broader standards, it is important to understand the controls that are relevant to containers and the cloud.

    As you consider your compliance program, be proactive—don’t wait until you are ready to roll into production. Start early by engaging your compliance team and helping them get up to speed. Your role is to provide evidence of compliance to pass an audit at any time using the documentation from your security platform.

    Getting Cloud and Container Security Right

    The move to the cloud creates a tremendous opportunity to get security right and reduce risk. The fact that physical security and a chunk of operations are delegated to cloud vendors frees up security and development teams to focus on their more narrow scope within the shared security model. By taking a secure DevOps approach and inserting security into every stage of the application life cycle, your team can confidently and securely run cloud and containers.

  • Learning from Loris Degioanni: Cloud-Native Days with Kubernetes Virtual Summit

    Learning from Loris Degioanni: Cloud-Native Days with Kubernetes Virtual Summit

    Keeping up with information can be challenging. With all these changes, you’re probably left wondering, “who can guide me through all this information?” Fortunately, Cloud-Native Days with Kubernetes is focused on giving attendees the tools they need to become proficient in cloud-native technologies. At the virtual summit, attendees can tune into our expert-led featured sessions and learn how to leverage cloud native technologies to move faster and more securely.

    Cloud-native technologies are quickly becoming an integral part of IT environments as organizations continuously accelerate their development efforts to meet business demands. Because of this, it’s incredibly valuable to learn from industry specialists changing the IT world as we know it. And who better to learn from than the industry thought leaders and doers in the cloud-native space? Through sessions touching on topics like security and observability, our featured tech titans will give you a better understanding of cloud native and its impact on the IT landscape.

    Today, the CI/CD pipeline is mainly built on open source tools – Kubernetes, Jenkins, GitLab, etc. Security has traditionally been closed, but it’s now clear the pace of innovation cannot be constrained by proprietary development models. Keynote speaker Loris Degioanni, CTO and founder of Sysdig, will discuss key practices needed for a secure cloud and container environment, including: what is required to increase security, visibility and simplicity in the cloud, lessons learned from major attacks like Kaseya and SolarWinds, ways to leverage Secure DevOps to not only ‘shift left,’ but also ‘roll right’ for detection and response, and how open source is the key ingredient to see all your signals in a constantly changing landscape.

    In his article, “Open Source is Taking Over Security,” published last year on The New Stack, Loris Degioanni elaborates on this idea that open source is essential to maintaining high security, stating, “I argue that, despite having lower penetration of open source, security is the industry that benefits the most from an open source approach. I also argue that open source will gradually take over and become the standard way to do security.” To understand this further, Loris breaks it up into a few key questions: Why is open source the best way to do security? and, Will open source become the standard way to do security?

    Let’s start with the most important question: Why is open source the best way to do security? Loris is adamant that open source is the key ingredient to security because of one thing – speed of innovation. Loris points out that the rise of widely adopted and open computing platforms like Kubernetes have had a big impact on how distributed, coordinated ecosystems can beat out a ‘behind closed doors’ single vendor 100% of the time. Loris writes, “On one hand, Kubernetes and cloud native have such a fast innovation pace that it’s hard for a vendor to keep up by itself. On the other hand, thanks to Kubernetes, for the first time we have a completely open platform to run our applications, where security can be natively integrated rather than being bolted on top.” 

    Open source also increases the speed of innovation because it empowers end users to work with vendors. Any user, regardless of size and level of sophistication, Loris says, can provide feedback in a tight loop and they can also contribute. So why is this relevant to security? As Loris explains, “The intrinsically fragmented nature of vulnerabilities and threats makes this bazaar-oriented approach to contributing very effective.”

    This brings us to Loris’s second question: will open source become the standard way to do security? Not only does Loris say yes, open source will become the standard way to do security, but in fact there is no escaping this. Using a metaphor of bad guys vs. good guys to describe cybersecurity battles, Loris says, “the army of the bad guys is big, smart, and aggressive. And the deck is stacked in their favor.” 

    So how do the good guys win in this scenario? Loris says the best chance at this is, “working together, as a team, leveraging each other’s strength, making sure that no energy is wasted.” Rather than having competing standards upheld by a variety of vendors, Loris is adamant that “a much better approach consists of leveraging a common set of standards that are deeply integrated in the platform, owned by the community, driven by consensus, on top of which all of the players can confidently innovate.”

    Much like Loris’s approach to open source, innovation and security are also valuable key practices at Cloud-Native Days with Kubernetes. Life moves fast. Innovation cannot afford to be slowed down, especially now. So begin your cloud-native information journey by tuning into our expert-led sessions, gathering your questions and learning from our talented speakers August 4 and 5 at 9 a.m. ET.