devopsy.kinsta.cloud

Tag: containers

How Containers Simplify DevOps Workflows and CI/CD Pipelines

DevOps enables organizations to capitalize on the flexibility of cloud resources in real-time, which is a huge game changer. Just as the adoption of Agile methodology can make a development team more responsive, DevOps revolutionizes implementation of IT objectives from end to end, from a waterfall-style process gating company productivity to a dynamic process that makes better-quality software fast and easy.

Organizations have been taking advantage of increasingly flexible resources and moving away from conveyor belt-style project delivery with hardware and software resource planning, ordering and integration. DevOps provides a way to address the question, “If we can provision resources quickly and easily, how can we complete entire projects with similar responsiveness?”

As DevOps lowers the wall between development and operations, staying sane and accountable doesn’t have to bog down processes. Structured communication still takes place, but in an iterative, incremental fashion, much like polishing a jewel.

Instead of lofty goals set in the somewhat-distant future, practical solutions can be created, deployed and adjusted. The process gets applications in the hands of end users far sooner, smooths any rough edges using actual user feedback, and helps organizations not only become more responsive to changing needs but make much more efficient use of valuable software development and operations resources.

Why Dev and Ops Teams Need to Collaborate

It can be hard for an organization’s culture to adapt to this level of change. But both development and operations teams have some pain points that help motivate them to work together more dynamically.

The development (Dev) side of the house wants to deliver more timely solutions, ensure greater acceptance of new applications and use its resources more efficiently. Operations (Ops) has challenges with hardware resource planning; they have maintenance and cost-reduction projects that are delayed. Ops also has insights into new features, efficiencies and integrations, but with no way to implement them.

These and other pain points arise when traditional, waterfall-style processes constrain communication and implementation. Creating a new flow between the two teams helps to reduce these pain points.

Rather than being tied to a specific technology, DevOps is a methodology aimed at making software development efficient. Containerization narrows the gap between development and IT Ops to a minimum. Containers are a great tool for enabling DevOps workflows and simplifying the development and delivery pipelines. Containers hold the code and dependencies required to run an application and reside in isolation. This enables teams to develop, test and deploy apps inside these closed environments. And this doesn’t affect different parts of the delivery, making the lives of testers and developers a lot easier.

Enabling CI/CD

DevOps has created a way to automate processes to build, test and code faster and more reliably. Continuous integration/continuous delivery (CI/CD) isn’t a novel concept, but tools like Jenkins have done much to define what a CI/CD pipeline should look like. While DevOps represents a cultural change in the organization, CI/CD is the core engine that drives the success of DevOps.

With CI, teams must implement smaller changes more often, but they check the code with the version control repositories. Therefore, there is a lot more consistency in the building, packing and testing of apps, leading to better collaboration and software quality. CD begins where CI ends. Since teams work on several environments (prod, dev, test, etc.), the role of CD is to automate code deployment to these environments and execute service calls to databases and servers.

The CI/CD concept isn’t entirely new, but it’s only now that we have the right tools to fully reap the benefits of CI/CD. Containers make it extremely easy to implement a CI/CD pipeline and enable a much more collaborative culture. Containers are very lightweight and can scale endlessly, run on any environment and are very flexible. It doesn’t get easier than this.

Now, you can move code across containers–or container clusters, as is the case with Kubernetes–instead of moving code among various virtual machines (VMs) in different environments. VMs are static and leverage a monolithic application architecture, whereas containers use a distributed microservices model. This opens doors to new benefits when it comes to elasticity, high availability and resource use.

As part of a DevOps team-oriented approach, team members can reach out to their peers and share innovation, feeding their knowledge and experiences into the evolving process. Development teams can put the new resources to use, taking advantages of technologies such as containers and Kubernetes to architect solutions. Working together, this cooperation lets Ops run with the solution, scale it, distribute and upgrade efficiently without delay.

Putting it All Together

DevOps has helped organizations reimagine their entire development lifecycle. And while DevOps brings cultural change, CI/CD is the core engine that makes DevOps successful. New tools like containers now make it easier for organizations to make the most of CI/CD. However, data storage must be taken into consideration, because it undergirds a dynamic DevOps environment. It also provides failover, disaster recovery and other essential availability and reliability features. Software-defined storage offers the flexibility that a dynamic DevOps environment needs. It’s a crucial element in the success of your DevOps program.

June 22, 2021
Report: The State of Cloud-Native Application Security

The cloud brings tremendous capabilities in terms of increased deployment fluidity and automation. Along with cloud adoption has come the use of cloud-native tools built specifically for developing applications for this domain. However, cloud-native tools carry some nuanced security concerns, such as misconfigurations, known vulnerabilities and leaked secrets. As such, 83% of organizations recognize security as very important to their cloud-native strategy, according to a recent report from Snyk.

Snyk’s State of Cloud Native Application Security report surveyed hundreds of IT professionals on their cloud-native security concerns. Below, we’ll pick out the top takeaways from the report, identify the most common trouble areas for cloud-native application security and see if there’s a correlation between deployment automation and higher degrees of application security.

The Move to Cloud-Native

Teams are moving to cloud-native tech, empowering DevOps with software-driven architecture and infrastructure-as-code (IaC). In this new cloud-native paradigm, 58% of production workloads are deployed as containers, 21% now are serverless and 50% use some form of IaC within the deployment process.

Organizations are moving to cloud-native technology for a variety of reasons. For one, containerized software affords increased speed — 68% of organizations moved to containers for increased deployment velocity, the study found. This is followed by ease of management (at 67%) and reduced cost (43%). There is also the security imperative for adopting cloud-native tools; 36% of respondents cited security as a primary reason for moving production applications to containers.

Top Cloud-Native Security Concerns

While cloud-native technologies such as containers, Kubernetes, serverless and IaC enable more rapid development, they also bring unique security issues. The report found that misconfigurations and known unpatched vulnerabilities are by far the most common type of incidents among cloud-native environments. In fact, 45% of organizations have experienced an incident arising from a misconfiguration, followed by 38% due to known unpatched vulnerabilities.

Other common cloud-native security incidents include secrets leaks, failed audits and malware. Interestingly, the study also found that data leaks by insiders are more common within organizations with higher degrees of cloud-native adoption. According to the report, 38% of organizations with high cloud adoption have suffered data leaks by an insider, whereas the figure is cut in half, at 17%, within organizations with low cloud adoption. Secrets like API keys must be managed carefully, especially as cloud-native tools force more dependencies. “The need for effective management of these kinds of artifacts is a key differentiator from the more centralized pre-cloud era,” the report noted.

Automating Security Testing

End-to-end deployment automation shows promise, yet is still at an early stage of maturity for most development teams. Though 95% of organizations use some kind of deployment automation, only about one in three organizations have an entirely automated deployment pipeline.

Organizations with increased deployment automation tend to embrace a higher degree of security testing, as well. Highly automated pipelines are twice as likely to use security testing throughout their development lifecycle, found the report. Since incidents most commonly arise from misconfigurations and known vulnerabilities, automated scanning could help identify many cloud-native issues, comparing production code against databases of known exploits.

So, when does this security testing occur? More often than not, it happens within the CI/CD pipeline. Over 60% of organizations perform security testing within the CI system. This is opposed to testing source code repositories or local IDEs and CLI tools early on in the development process. In terms of testing frequency, there is a wide range of executions. For those groups with high deployment automation, 70% test security daily or more frequently. Automated security testing seems to be functioning well, as 72% of fully automated teams find and fix critical vulnerabilities in under one week.

The report also exposed an interesting disconnect with regard to security testing ownership. Only a small percentage of security engineers (less than 10%) feel developers are responsible for the security of the cloud-native environment and applications, whereas 36% of developers stated they are responsible for security. These figures may demonstrate the security onus shifting left toward the development side. Or it could underline changing attitudes as full-cycle development becomes more realistic. Regardless, teams will have to find clarity on roles to avoid some difficult conversations!

Cloud-Native Security

With the shift toward cloud-native strategies, security standards are rising to respond to new issues like misconfigurations. To address mounting application threats, increased automation could help shift security left—this and other reports clearly demonstrate a correlation between fully automated deployment pipelines and an increased security testing regimen.

As a result of cloud-native adoption, 58% of organizations have increased their security concerns since adopting cloud-native tools. Part of this involves moving to a zero-trust approach across all infrastructure, whether internal or external facing. The report revealed that 58% of organizations are increasingly concerned with misconfiguration, 52% are increasingly concerned with insecure APIs and 43% are increasingly concerned about known unpatched vulnerabilities, while 41% are concerned about secrets leaks. Hopefully, these benchmarks will help you see how your organization stacks up in comparison to others.

Snyk’s State of Cloud Native Application Security report questioned 600 experts in development, security and operations on cloud-native adoption and security practices. For more insights, view the study in its entirety here.

June 22, 2021
Majority of Orgs Lack Visibility Into Container Vulnerabilities

Today’s blend of third-party application dependencies and polyglot software development often makes assessing risk difficult. With many new cloud-native deployment models, it can be tricky to discover potential vulnerabilities. These threats take the form of insecure default settings in Kubernetes, over-permissive states, CVEs that threaten container integrity, and other vulnerable conditions.

Plugging gaps throughout the cloud-native strata is now crucial to avoid exposing data and breaking privacy regulations. Yet, gaining visibility into these holdings is challenging, and traditional application security practices may not cut it within a cloud-native context.

A new 2021 CISO Report released by Dynatrace, “Precise, automatic risk and impact assessment is key for DevSecOps,” demonstrates increased false positives and a general lack of real-time container runtime vulnerability scanning among enterprise IT departments worldwide. Of the 700 CISOs surveyed, most report that microservices, containers and Kubernetes have caused security blind spots across their organizations.

Below, we’ll cover the major takeaways from the study to see why new cloud-native development models are leaving security gaps. We’ll consider how CISOs can increase security throughout the cloud-native IT stack while still reaping the rewards of container-based delivery models.

Cloud-Native Security Blindspots

Adopting new container-based technologies may introduce multiple nuanced security implications. Of the tech leaders surveyed, 89% report that microservices, containers and Kubernetes have created new vulnerabilities within their organizations.

Engineers are shipping code to maintain release velocity and to meet the demand for digital innovation. In the process, 28% of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery. Due to these realities, it’s no surprise that 71% of CISOs admit they are not fully confident code is free of vulnerabilities before going live in production.

As some teams bypass security pre-production, it follows that more aren’t applying holistic security scanning during production. As a result, nearly all organizations (97%) lack real-time visibility into runtime vulnerabilities, found the report.

Adding to the number of cloud-native blindspots is information overload. The report calculated that, on average, an organization receives a staggering 2,169 new alerts of potential application security vulnerabilities each month. Out of this high volume of alerts, 77% of CISOs say they are mostly false positives and not actual exposures.

Due to minimal testing and a high number of false positives, organizations are likely to leave many vulnerabilities unpatched. To make matters worse, developers, pressed for time, may lack the bandwidth to resolve known issues.

Faster Delivery, Harder Detection

Much of the setbacks in vulnerability detection may lie in a general shift toward new ways of working and faster delivery cycles. For example, 63% of CISOs reported that DevOps and agile methodologies are making it harder to detect and manage vulnerabilities.

In addition, 74% of CISOs say traditional security controls such as vulnerability scanners no longer fit today’s cloud-native world, and 77% of CISOs agree that automation could help. This could involve replacing manual deployment, configuration and management with more automated approaches. Others agree that security-as-code is required to ensure high container security best practices.

Another result of more frequent delivery is increased over-reporting. Of the total security vulnerability alerts received per month, CISOs report that only 42% of these alerts require action. More rapid release cycles could thus exacerbate already crowded vulnerability detection systems.

Who Owns Vulnerability Management?

Only 3% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments, the study found. In reality, vulnerability scanning in production is only happening once a month or less within 68% of organizations.

To compensate for this gap, most CISOs believe the onus is not on the security team but the application and DevOps teams to manage and respond to vulnerabilities—85% of CISOs believe these groups should hold responsibility for vulnerability management. These findings come to light as other stakeholders advocate for increased full-cycle developer control and encourage the DevOps mindset across roles.

Handing more control to developers sounds good, yet, 64% of respondents say developers don’t always have time to resolve vulnerabilities before code goes into production. As a result, over one-quarter of application teams bypass vulnerability scanning entirely. Often, engineering teams may not frequently sync with security groups, and DevSecOps principles are not yet pervasive throughout all organizations.

The report also highlighted the fact that existing security tools are often ineffective; 69% of CISOs say security tools slow down DevOps because they only focus on one state of the software delivery cycle.

Cloud Use Requires Security Repositioning

As cloud architectures rise in prominence, organizations are adopting cloud-native tools like microservices, containers and Kubernetes. There is also the chance of multi-tool conditions further complicating the vulnerability scanning process. With more systems to protect than ever before, teams may have to reposition their approach to vulnerability detection.

“The increased use of cloud-native architectures has fundamentally broken traditional approaches to application security,” said Bernd Greifeneder, founder and chief technology officer at Dynatrace. “This research confirms what we’ve long anticipated: manual vulnerability scans and impact assessments are no longer able to keep up with the pace of change in today’s dynamic cloud environments and rapid innovation cycles.”

The Global CISO report, “Precise, automatic risk and impact assessment is key for DevSecOps,” from Dynatrace, queried 700 chief information security officers (CISOs) on their monitoring practices concerning vulnerabilities. To review the report’s full findings, you can download it here.

June 14, 2021
Secure Kubernetes Architecture: Six Factors Essential to Success
Kubernetes has become the go-to container orchestration tool for businesses.

Check out these telling stats [source: Enterpriser’s Project]:

84% of companies are using containers in production.

Of those, 78% are using Kubernetes to manage their containers.

69% of companies have found security holes due to misconfiguration of their Kubernetes environment.

Your Kubernetes architecture is like a large house with container “tenants” living inside it. You’ll need to build it with care to make sure it’s a safe and happy place to live.

Here are six essential factors to get right when planning (or auditing) your Kubernetes architecture.

Setting the Foundation: Underlying Platform and Control Plane Configuration

The foundation of a house is a critical first step. A weak foundation leads to cracks over time.

Similarly, where you install Kubernetes is your first choice. There are several options available, each with pros and cons.

Kubernetes is a cloud-native tool. Therefore, it makes sense to install it on the cloud. There are two cloud deployment options: Infrastructure as a Service (IAAS) or Platform as a Service (PAAS).

An IAAS installation involves creating a series of virtual machines in the cloud (for instance, using Amazon EC2) and installing Kubernetes on those machines. You’ll be responsible for updates and configuration of the Kubernetes installation.

On the other hand, all major cloud providers offer managed Kubernetes services. This deployment model allows you to use Kubernetes without having to handle the infrastructure.

Even though Kubernetes was made for the cloud, you don’t have to install it in the cloud. An on-prem installation is an option, with many companies choosing to use their virtualization infrastructure to host Kubernetes.

You’ll find a quick summary of the pros and cons of each choice below.
‍

Your decision depends on three factors:

The skillset of your team

Your need for control and flexibility

Your company’s goals

Control Plane Configuration

The Kubernetes Control Plane consists of the services run on the Master node. The cluster store, scheduler, controller manager, and API server combine to create the control plane.

Plan your control plane security well. If an attacker gains access to your control plane, they’ll be able to control your entire Kubernetes cluster. Use SSH or a VPN / VPC to connect to and use the control plane.

If you’re using a managed service from a cloud provider, protect your API keys and credentials. Don’t ever store them in a source control system. Losing your API keys would lead to a complete takeover of your cloud infrastructure, not only your Kubernetes installation.

Finding Good Tenants: Container Security and Composition Analysis

The wrong tenants can destroy your house. Similarly, dangerous containers can bring down your Kubernetes environment.

Make sure any containers you bring in from the outside are vetted and configured correctly. Only use trusted registries, such as Docker Hub or Quay.io.

Finally, scan your containers before using them. You can use open-source container scanners to find vulnerabilities and malware. You can integrate most scanners into your CI/CD pipeline.

Plan Your Rooms Wisely: Kubernetes Cluster Partitioning

The rooms in your house each have a different name and purpose. You don’t keep a stove inside your bedroom or a bed in the kitchen. You give tenants private rooms while allowing them to share common areas, such as the kitchen.

In Kubernetes, namespaces allow you to separate various applications within the same cluster logically. If the cluster is your house, each namespace is a separate room within it.

Give namespaces to each application within your cluster. This practice produces three benefits:

Logically separates applications and environments (Development, Staging, Production)

Allows for robust Role-Based Access Control (RBAC)

Allows for network partitioning for added security within the cluster

Kubernetes RBAC Primer

You can check out the Kubernetes docs for comprehensive explanations of RBAC within Kubernetes. But here’s a quick primer for those who don’t have the time to read it now.

Kubernetes has Roles and ClusterRoles. They contain rules that represent a set of permissions. There are no “deny” rules, so you have to know what access is necessary.

Each Role is scoped to a specific namespace. ClusterRoles, on the other hand, have no namespace. In Kubernetes, an object can only be namespaced or not; it can’t be both. Therefore it’s necessary to have two resources, one for each scenario.

Use Roles to create permissions tied to a specific application. Use ClusterRoles for access to cluster-scoped resources or resources used by multiple namespaces.

RoleBinding and ClusterRoleBinding is the act of assigning permissions to a specific user. A RoleBinding grants permissions within a single namespace while a ClusterRoleBinding grants access cluster-wide.

For example, assigning the “pod-reader” Role to the user “jane” in the “default” namespace allows “jane” to read pods in the “default” namespace.

Roles define a set of permissions. Then users, groups, or service accounts (collectively called “subjects”) are assigned roles to grant access to specific resources within the cluster.

Define network partitioning and access control appropriate for the business’s needs before deploying any application into your cluster.

Watch Your Wiring: Inter-Pod Communications

Shoddy wiring is more than an inconvenience. It can lead to damaging fires or even destroy the entire house.

Similarly, poor inter-pod communications can bring your Kubernetes cluster grinding to a halt.

A Kubernetes environment is a small network ecosystem. The same network topologies, protocols, and policies govern pod-to-pod communication as those you’d find in any corporate network.

A full discussion of Kubernetes networking is beyond the scope of this article. You can read up on it using the Kubernetes networking documentation. But here are some quick pointers.

You can use Service Topology to define how traffic flows to and from a particular service. For example, a service can specify that traffic should be routed to endpoints on the same node as the client.

Service Topology is useful in the public cloud. You can use it to keep a service’s traffic in a particular availability zone or region to reduce latency.

Another useful networking tool is NetworkPolicies. These application-level constructs specify how a pod is allowed to communicate with other entities. This feature is especially useful when you want to control network traffic using IP addresses or ports.

Finally, you need to have a robust authentication and authorization strategy. We recommend using a service mesh to simplify load balancing, service discovery, encryption, and authentication. For example, service meshes include support for OAuth, which makes service authorization much easier to manage.

Secure the Front Door: Ingress Architecture

There’s no point in building a secure home and then leaving the front door unlocked. You don’t want to do that with your Kubernetes cluster either.

In Kubernetes, Ingress exposes HTTP and HTTPS routes from outside the cluster to your services within it. Ingress is your environment’s “front door.”

[source: Kubernetes docs]

Carefully consider which server to use in your Ingress architecture. NGINX is a tried and true web server with all of the security features necessary to protect your services. NGINX now offers an Ingress Controller for cloud-native Kubernetes environments.

However, you may want to give Envoy a look. It’s an open-source edge and service proxy built by Lyft specifically for cloud-native applications. It tackles the common observability and network debugging issues common in a microservice architecture. Envoy can also serve as a service mesh.

As the “front door” to your cluster, the choice of an Ingress server also impacts security. You can use it to terminate TLS connections from clients before they access your services. Be sure to include a key management strategy, including a Key Management Service or another secure vault.

Remember to follow the same security practices for your Kubernetes cluster as you do for any other part of your network infrastructure. Watch for OWASP Top 10 and OWASP API Top 10 vulnerabilities as well as logic-based threats.

(Hint: Traceable watches for common and logic-based vulnerabilities by learning the business logic of your microservice applications. Check it out for yourself here).

Finally, make sure your ingress plays nicely with mobile and IoT devices if you serve those clients.

Install Security Cameras: Secure and Monitor Microservice Communications

Video doorbells and security cameras are becoming commonplace. Homeowners want to know what is happening in and around their house.

Securing and monitoring within your Kubernetes cluster is equally critical. Make sure that microservice communications are protected, and you know what requests are being sent between services.

Consider point-to-point encryption between all microservices. And ensure real-time API monitoring for both REST and gRPC protocols.

Zero Trust principles not are becoming more popular as new technologies are appearing that support it. Zero Trust is an operating model where no traffic is trusted by default, inside or outside your network.

Within Kubernetes, implementing this model means verifying every request, client, or object trying to connect to your services. Nothing happens within your cluster unless the user or service account has proven that they have permission to act.

Zero Trust is essential to cloud-native security. At any moment, dozens or hundreds of services are trying to perform actions and share information. Zero Trust ensures that every request is validated and there are no holes due to the assumption that internal traffic is automatically safe.

Protect Your House

The world of microservices and cloud-native architecture unlock countless opportunities for businesses today. But new technologies also come with new dangers; new opportunities for malicious actors to steal sensitive information.

We’ve discussed six essential factors for securing your Kubernetes architecture:

1. Choosing the underlying platform and control plan configuration
2. Vetting and securing the containers running in your environment
3. Implementing cluster partitioning and access control
4. Defining inter-pod communications
5. Choosing your Ingress architecture (protecting your “front door”)
6. Securing and monitoring your microservice communications

With these factors in mind, what should your next steps be?

If you have an existing Kubernetes installation, use these factors as a mini-audit. Review your current policies and see how well they match up in these six areas.

If you’re planning your first Kubernetes installation, use these factors as a guide to making sure you cover all of your bases. Meet with implementers and make sure you have a plan for all of these factors.

Then your Kubernetes environment will be a happy home for your microservices.
May 11, 2021
Languages and DevOps: Can’t be Contained

The evolution of platform is an interesting study. From physical to virtual to cloud to containers, the progression has been steady, and each successive platform has benefits for both Dev and Ops that make them appealing. In the case of containers, portability is the word.

As easy to fold into your DevOps toolchain as cloud, yet able to be deployed wherever you need, containers have absolutely taken the industry by storm. While all cloud vendors offer container options these days, their “value add” capabilities are thinly veiled attempts at vendor lock-in, so most organizations have avoided them.

Development languages are as diverse as they are for physical or cloud; you can pretty much find containers hosting every language imaginable. That makes perfect sense, since one use of containers is to keep an otherwise-obsolete environment alive. That’s certainly not the primary use of containers, but it is an important one. The catch with containers is that the primary languages depend greatly on usage. A container that is persistent and intended to last months or even years will tend toward a different set of languages than one that is ephemeral and intended to last only minutes.

The big weaknesses of containers – security, persistent storage, and management – have been addressed more and more as container usage has grown. Complexity of environments is now the big issue, but that is not inherent to containers; merely enabled by the ease with which new machines can be spun up.

For longer-term containers, Java and C# are still the languages of choice, though others are certainly making headway. A combination of how new container technology is, and the extra layer between applications and hardware in the current popular container solutions make C/C++ less popular than on physical machines. They are still used because like other targets, containers still have operating systems that are linked to more easily in these languages.

Shorter-lived containers tend to use languages that grew up in the Agile environment – from Python to JavaScript to Go. The ability to quickly crank out the code and get to test is useful for Agile and DevOps environments.

Hooking into DevOps toolchains is at least as easy as it is in a cloud environment. There are even a fairly large number of companies that have moved to spinning up a container to build, then destroying it, only to do it all again on the next build. This is not mainstream yet, but the ability to completely configure the container and its loaded toolset makes it an appealing option.

The kicker – one that cannot be overstated – is that it is simple and easy to get developers running with a copy of a complex system that once would have required several physical boxes. I, personally, have worked on a seven-plus server client system that I had a complete copy of on my (admittedly beefy) development laptop. It wasn’t the most performant, but it was enough to do unit testing.

The security weaknesses of cloud come along with containers too – there is a lot more than just configuring an IP to directing traffic, for example – but mitigating tools and processes are available.

This pundit truly believes that containers are the future of DevOps. They have the best of previous iterations, while offering mobility that just didn’t exist in other solutions. The ability to move an entire infrastructure from one deployment target to another (data center to cloud, for example), or from one cloud vendor to another makes this option the king for organizations that require (for business objectives, compliance or finance reasons) the ability to move their applications quickly.

Meanwhile, rock on.

Containers are the cutting edge of wherever it is we are headed. They are more agile than any other solution, they do not limit programming or networking options, can be run wherever the organization needs them and can be modified or redeployed easily. There is more complexity, but most of it has been obfuscated; only when things go terribly wrong is the complexity really an issue. Development for containers, with a few exceptions, is development for the target OS. That makes it easy to keep the organization’s systems preferences while enabling developers. All good. And many (I daresay most) of you are already taking advantage of them. Keep rocking it. Use what the org needs, and don’t forget to check every once in a while to make certain what is in use is what needs to be in use.

April 1, 2021
Languages and DevOps: Traditional

For quite a while now, all the cool kids have been going on and on about “full stack development,” “API first,” and a ton of similar methodologies/practices. And yet, a huge swath of applications are still targeted at a single system to do a specific job. There are fat clients, there are internal servers, there are standalone apps. All are still in development, and the hype machine doesn’t account for them much, though they’re pretty pervasive.

We still have to maintain them, or write yet another. They’re not going anywhere, because there are some problems for which they are the right solution. So let’s talk about them.

For clarity, I’m defining traditional as, “Targets a specific OS/hardware platform, and is not primarily web-based.” We’ll exclude mainframe, because the toolsets and integration with DevOps are still different enough to warrant their own blog.

Online forums are full of people trying to re-target traditional apps (perceived Windows 10 issues caused many to want to move from Windows, and the growing Linux trend of making distros into beta – or even alpha – testers has many wanting to move from Linux), while others are just trying to keep them running as the world changes underneath their feet.

Easy Integrations

While these dev tools are the ones that Agile grew up around, that makes them well-integrated into Agile and DevOps. The feeds to/from compilers and various build tools are the same as other spaces we’re looking at (or, more precisely, the others are the same as traditional), so integration of AppDev is generally not an issue. Integration of Ops is harder, but exists. The various DevOps tools with an emphasis on operations (I like to call it devOPS as opposed to DEVops) are available to traditional development, and you can certainly deploy through them, but they’re like the second cousin to “full stack.” Good Enough rules the day, and a little work will be required. Thankfully, tools like Ansible and Puppet smooth the way a bit for deployment, not caring much if you’re deploying a traditional app or a web service, as long as you tell them what to do to successfully deploy.

You got to move it, move it…

Portability is increasingly becoming an issue. The rise and fall of “preferred” Linux distros, the costs of being a Microsoft shop … there are a lot of reasons to want to move your app around. The best first step to this (and the only step some will need, IMO) is containerization. Put it in a container, and your underlying hardware can run on whatever OS the corporation settles on, while your apps will run in containers on the OS they need. For most organizations, this will only be a stop-gap; a way to quickly move servers away from one OS and onto another, but the apps will have to move fully to the new OS, eventually. Microsoft has Windows Subsystem for Linux, which can help move from Linux to Windows, and Linux has Wine to help run Windows apps on Linux. Both have come a long way toward interoperability, but neither is perfect – or even easy. It will take a bit of work, but far less than rewriting for the target OS top-down. Tools like Cygwin are also available to get your Linux app running on Windows if you don’t want to use Microsoft’s solution. In the end, you are going to have to modify code, but you are porting an application, so no surprises there.

Consider the future

A place I worked in the late 90s/early 2000s had an OS/2 machine that was critical infrastructure. We were not allowed to touch the box. I think if the admins had their way, we wouldn’t have been allowed to look at the physical box. Of course, we virtualized it just as soon as we could in a step similar to my “containerize” advice above. Now is a good time to consider writing your apps with an eye toward portability, so you can remove this type of system from the equation. That RHEL 5, or Windows XP app should really be modernized or eliminated at this point. The tools for cross-platform development are out there, from Mono to Java to Xojo; platform-dependent bits can be isolated for rapid retargeting. It’s up-front work that pays off in spades when the time comes to change the targeted platform.

You. Rock.

Whatever your language of choice, in the end, it will likely be your build tool that links it to DevOps. Your biggest concern for DevOps will probably be portability in the near future. Meanwhile, keep rocking it. You’re doing the work that needs doing, even if it isn’t the part of DevOps everyone is currently buzzing about.

March 12, 2021
Windows Sandbox and Hypervisor-Based Isolation
Completely securing the endpoint is hard. Securing it without sacrificing user productivity is even harder. Think of a modern laptop running a Windows 10 OS, for example. The OS consists of millions of potentially vulnerable lines of code. It has many legacy components written with old security standards in mind. The kernel is probably executing several third-party drivers that might also be vulnerable. Finally, there are dozens of daily-use applications. Some are provided, managed and patched by the enterprise, while others are installed on demand by users; the latter are not always from legitimate sources, making it harder to track and assess security. Timely detection and prevention of threats is a cat-and-mouse game, where a single win for the attackers is game over for the user.

Consider, too, the rate at which organizations are moving to the cloud. For those using the endpoint purely as a browser, web isolation products can significantly enhance security by isolating browser access to risky websites and, sometimes, to risky email attachments, too. Using ChromeOS, an operating system built for the cloud with security in mind, can provide additional security benefits.

But using only a browser is not yet practical for most organizations. Many legacy line-of-business applications are still being used daily. Workers install video conferencing applications to meet with business partners. Developers install and update software for their daily work. Almost every popular, modern cloud application (Slack, Teams, Office, etc.) comes with a full desktop client that offers superior features. For organizations looking to adopt these tools, web isolation solves only part of the problem.

VDI or Desktop-as-a-Service (DaaS) solutions allow companies to shift corporate application workloads to the data center or the cloud. By limiting endpoint operations to that of a thin client, and only connecting them to this infrastructure, the list of potential attack vectors narrows and becomes very secure.

But using VDI/DaaS for the entire organization becomes very expensive if massive numbers of users need remote access simultaneously. Further, the user experience and latency are far from ideal, and offline work is impossible. In terms of security, while the endpoint is now more secure, the threat still exists – it just moves to the data center or the cloud, where, in essence, a fat Windows desktop is running. With DaaS, security might be even more challenging when multiple users share the same virtual OS; a single threat can potentially compromise multiple user sessions at once.

Hypervisor-Based Isolation

The world trusts modern hypervisors to securely run servers, containers and other workloads in the cloud. Sometimes, multiple hypervisors run side-by-side on the same physical server, though they’re completely separated and isolated from each other. Unlike modern OS kernels, hypervisors are designed to perform a very specific task. Their code base is usually very small, well-reviewed and thoroughly tested, making it very hard to exploit. Empirically, it’s very rare to see a hypervisor-related vulnerability discovered or published.

Is it possible to secure the endpoint with hypervisor-grade isolation? Imagine a “productivity environment” where workers can browse any website; open any email attachment or install and execute software, all without endangering the corporate environment or the organization’s crown jewels. Even better, malware or attackers who compromise this environment are trapped inside by strong, hypervisor-based isolation boundaries.

Windows Sandbox

Microsoft has been investing a lot in virtualization-based security (VBS) in recent years. Hypervisor-based isolation is a key element, whether it’s used to isolate LSA secrets with Credential Guard or to isolate critical Device Guard code. With the release of Windows 1903, Microsoft has introduced Windows Sandbox, describing it as a “lightweight desktop environment tailored for safely running applications in isolation.” Windows Sandbox enables users to spin up, almost immediately, a second, isolated instance of Windows with a click of a button.

Windows Sandbox is based on the new “Krypton VM Containers” – Hyper-V-backed lightweight containers. The lightness is reflected in:
- Reduced disk space: The container reuses the host’s binaries, reducing its disk footprint and making it easier to manage. This also means it remains as patched and secure as the host.
- Optimized memory and CPU usage: The host’s kernel is aware of the container, and manages it as yet another application. That means improved CPU and memory allocation based on actual demand and usage.
- Paravirtualized GPU: By enabling GPU acceleration inside the container, the CPU has less work to do.
Unlike web isolation products, Windows Sandbox can isolate almost any application. With the Krypton optimizations, it’s fast and doesn’t place too many demands on hardware (any three-year-old laptop should suffice), making it dramatically more affordable than VDI. The virtualization layer is barely noticeable, making the performance superior to VDI/DaaS.

The Missing Pieces

Can Windows Sandbox enable organizations to provide an isolated “productivity environment” while further hardening and securing the host OS? In theory, it could, but in practice, unfortunately, it lacks certain capabilities necessary for enterprise environments:
- Manageability: It’s hard to deploy and impossible to manage (policies, applications) Windows Sandbox with MDM systems such as Microsoft Intune.
- Usability: Windows Sandbox is non-persistent. Applications installed by users or administrators are going to be wiped on reboot. User settings, cookies, and browsing history will not be saved.
- OS integration: While users can install risky software inside the container rather than on the host, they are not forced to do so.
- Security: While fully isolated in terms of code execution, Windows Sandbox doesn’t provide network isolation. Malware can access and attack other devices accessible by the host, even if behind a Network Access Control (NAC).
- Software Compatibility: Some applications fail to run or to be installed inside Windows Sandbox.
Hypervisor-based isolation has clear benefits over traditional security methods. By avoiding the cat-and-mouse game, and moving to “mitigation by isolation”, organizations can increase security and productivity, and reduce costs. Once some of the aforementioned gaps are filled, hypervisor-based isolation could become the future of endpoint security.
January 7, 2021
Up Your DevOps Game: It’s Time for NoOps

NoOps is here and it’s more than just a buzzword or an ideal. The next generation of platform-as-a-service (PaaS) platforms are evolving to minimize the developers’ operational burden and reduce dependency on DevOps for deployment. Dev teams that don’t want to deal with operations or don’t have in-house operations resources should consider deploying applications on a NoOps platform.

To understand the concept of NoOps, we need to start with an understanding of how deployment management has evolved over the decades.

From Hardware and Software and Back Again

It’s been a long trend of back and forth between developers and “deployers.”

It was once mandatory for software developers to be fluent in the hardware for which they were creating software. They wrote the code and then worked with the operations team to deploy it on in-house servers. Everything was tightly coupled. The first mainframes—IBMs and SiliconGraphics machines—ran on custom-built software, and the developers were responsible for the deployment and management. The developers had the machine first, and then had to create the code to make them run—assembly or low-level language or even hardware code; rope memory, in some cases.

Then came the x86 revolution, when hardware became more standardized and was decoupled from the complexities of deployment. Developers started focusing on the software and organizations had separate teams that would manage the deployments.

With the advent of virtualization and infrastructure as a service (IaaS), the deployment of software now depended on APIs for infrastructure provisioning, and we returned to an integrated development and deployment function—in other words, DevOps.

The Problems DevOps Created

The problem then became one of choice: As APIs multiplied, developers had to decide which APIs would be most relevant, efficient and useful to deploy their software—and on what infrastructure: bare metal, virtual machines such as EC2 and VMWare, Kubernetes, Swan, OpenShift, serverless, Lambda, Knative, etc.

Not only did the teams have to decide on what IaaS to deploy the actual software, but they needed to also choose how and where the layers and logs would be monitored—and even where those logs would be stored. They need to consider things such as traceability and horizontal or vertical scaling issues, to name a few.

This has resulted in the creation of bespoke permutations and combinations that work great … until vendors’ upgrades require them to keep up with tens or hundreds of configuration changes. Most teams are keeping it together, but it definitely can be done more efficiently.

Now It’s time to Up the Game to NoOps

It’s time for the next approach: Limit the number of choices to create standard best-in-class operations that deliver economies of scale and easily evolve with minimal hassle.

NoOps simplifies cloud operations—everyone can do things the same way. NoOps aims to “completely automate the deployment, monitoring and management of applications and the infrastructure on which they run,” according to Forrester, which coined the term.

NoOps is about standardizing the approach to deployments and reducing the number of variables, bringing simplicity. At its core, NoOps is focused on automating deployments and executions that are predictable and repeatable.

NoOps & Standardization

The development and increasing adoption of containers are critical to the entire NoOps philosophy. Containers provide the ability to independently deploy services and applications, automating and standardizing the process to deploy anything, anywhere. Using containers delivers the tremendous portability that hasn’t been seen since the development of generic hardware.

With encapsulation within the container, whatever is running inside will behave the same no matter where it is deployed.

The NoOps-containers movement will transform the entire DevOps industry.

Let’s go back even further. In the 1800s, few homes had electricity. They hooked up whatever appliance they had to whatever generator they were running and kept their fingers crossed. Once governments took over the role of bringing electricity to every home with standardized voltages and outlets, the appliance industry took off.

A true NoOps platform will provide a standard “socket” that works for everything. The developer will simply build the app, and it will “plug in” anywhere. With NoOps, developers don’t have to worry about how the application will work, deploy or scale, nor do they have to consider reliability or elasticity. The platform will deliver it automatically.

The “Gift” of Containers

Containers free developers from managing infrastructure and reduce the operational burden associated with building and deploying applications. They also minimize application conflicts among different environments and improve portability and team collaboration.

Containers make application deployment easier than ever before. Continuous integration doesn’t change as part of this process. Adopting containers as part of NoOps simply automates continuous delivery—developers write the code, commit the changes and push it to the container’s remote repository. Based on the Docker file, an image will be built and the containers that run your application will be deployed. Since all deployments are rolling, no downtime occurs.

Leveraging containers provides speed, agility and flexibility to any infrastructure, thus bringing cost savings and dynamism. Containers can flexibly host microservices, which can be scaled individually, as necessary. Using CPU, memory or even custom business rules, developers can set auto-scaling policies so applications are ready to serve an increased number of requests whenever needed. As the platform monitors application performance, it can use these insights to intelligently architect a right-sized infrastructure.

Putting NoOps Into Play

If you’re considering adopting NoOps, look for a PaaS provider with the expertise to make the right platform choices for you based on your application development language of choice. For example, if you are looking to host a Ruby application, ensure that the provider has the requisite Ruby expertise.

A true NoOps platform will streamline deployment, automatically scale based on your business requirements and provide outstanding performance. The automation dramatically boosts productivity and reduces costs associated with deploying and managing applications.

NoOps platforms monitor operations and automatically resolve issues using built-in observability mechanisms and intelligent alerts. Centralized logging, metrics and traceability make it easy to identify issues and initiate fixes without expensive downtime. Moreover, the platform should ensure strong security boundaries and adhere to applicable compliance regulations.

When “going NoOps,” also make sure that the solution provides comprehensive documentation and 24×7 support for emergencies that would normally be handled by an in-house DevOps team.

Wrapping It Up

NoOps can eliminate much of the work associated with deploying and monitoring applications by simplifying and streamlining operations and reducing the need for extensive in-house DevOps support. While it’s not a one-size-fits-all solution, it delivers great value helping companies of all sizes from start-ups to enterprise teams save time and money and better redirect their resources toward high-value activities, creating the best code to deliver the highest quality products.

December 21, 2020
Red Hat Automates More Operating System Tasks

Red Hat today announced an update to Red Hat Enterprise Linux (RHEL) that automates a wide range of manual tasks.

Scott McBrien, a principal product manager for Red Hat, said RHEL 8.3, available in a few weeks, expands the Red Hat System Roles capability that provides a prescriptive and automated means of managing operating system configurations. Red Hat System Role now addresses kernel and log settings, identity management, certificate management and Network-Bound Disk Encryption (NBDE), as well as deployments of SAP HANA databases and SAP NetWeaver middleware. Red Hat has also updated Tuned, a set of pre-configured performance profiles it makes available.

In addition, RHEL 8.3 provides an update to Application Streams, a set of developer frameworks, databases, container tools and other resources that now adds support for Node.js 14, Ruby 2.7 and other current versions of tools and languages. Red Hat is now committed to streaming support for updates to the frameworks include in Application Streams versus only making updates available each time the entire platform is updated, said McBrien. That approach is intended to make it possible for developers to embrace new capabilities faster while maintaining support for previous versions of frameworks, said McBrien.

Red Hat is also furthering its effort to encourage organizations that have standardized on RHEL to embrace its tools for building and managing container applications. Updated container images for Buildah, a tool for building container images and Skopeo, a tool for moving container images across storage platform, have been added along with version 2.0 of Podman, a tool for managing containers and images that adds a REST application programming interface (API) that is compatible with Docker Container Engine.

Red Hat is making the cases for a more modular approach to deploying tools for building and maintaining containers as an alternative to a more monolithic approach pursued by Docker Inc., said McBrien.

Finally, Red Hat has added Secure Content Automation Protocol (SCAP) profiles for the Center for Internet Security (CIS) Benchmark and the Health Insurance Portability and Accountability Act (HIPAA).

RHEL and the Red Hat OpenShift application development and deployment platform are at the core of the hybrid cloud computing strategy being advanced by Red Hat and its parent company, IBM. According to a Red Hat Enterprise Open Source Report, 63% of organizations surveyed have a hybrid cloud architecture today, with more than half of those who do not have one in place planning to implement one in the next two years.

Beyond bundling developer tools with RHEL to reduce the number of IT vendors, an organization needs to engage, McBrien said Red Hat is committed to automating as many low-level IT tasks as possible. IT teams should be able to deploy operating systems in the cloud just as easily as they might in an on-premises IT environment, he noted.

It may be a little while yet before every manual IT task becomes automated, but with each new update to the operating system the number of those rote tasks that IT administrators need to devote time to continues to diminish.

October 29, 2020
Upcoming Event: Operationalizing Kubernetes Virtual Summit
As Kubernetes keeps gaining traction in mainstream IT environments, the next big challenge IT teams will face is operationalizing the platform at scale. On Oct. 1, at 10 a.m. EDT, leading Kubernetes and cloud native communities will come together at the Operationalizing Kubernetes Virtual Summit to explore the tools and best practices you need in order to secure and manage one of the most powerful, yet complex IT platforms in the world.

Today, organizations are managing not just one or two Kubernetes clusters, but entire fleets as their infrastructures increasingly depend on Kubernetes for automating deployment, scaling and operations of applications. As such, operationalizing Kubernetes is paramount to a successful environment.

The free, interactive virtual conference brings Kubernetes technologists, DevOps and cloud-native experts together to share their knowledge and insights with the community. Attendees will find out how organizations such as AWS, Microsoft, CloudBees and many others are embracing containers and microservices environments.

Operationalizing Kubernetes Virtual Summit features an exceptional lineup of industry leaders, including:
- (Keynote speaker) James Strachan, distinguished engineer at CloudBees
- (Keynote speaker) Priyanka Sharma, general manager at CNCF
- (Keynote speaker) Liz Rice, vice president of open source engineering at Aqua Security
- Tracy Miranda, director of open source community at CloudBees
- Michelle Noorali, senior software engineer at Microsoft
- John Willis, senior director of the Global Transformation Office at Red Hat
- Bob Reselman, analyst at Accelerated Strategies Group
- Prashanto Kochavara, director of product at Trilio
- Pankaj Gupta, senior director of product marketing at Citrix
The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch the sessions by industry experts. Attendees will have the opportunity to interact, in real time, with speakers and sponsors, and will have the chance to participate in contests to win incredible prizes.

Stay tuned for speaker announcements and more summit details. For more information and to register, visit the Operationalizing Kubernetes Virtual Summit.
August 12, 2020