In this video from the Red Hat Summit 2018, Chief Security Architect Mike Bursell takes an enthusiastic look at three open source security technologies: DevSecOps, serverless computing, and Trusted Execution Environments.
These technologies are examples of where Red Hat’s longview is aimed for the security realm.
Open source software is good. Open source plus open data is even better. That makes initiatives such as the Open Data Hub both useful in and of themselves and as a template for maintaining control over your data.
Access to, and the ability to collaboratively build upon, open source code is genuinely useful. If it weren’t, open source software wouldn’t have become such an important part of how technology has developed over the past couple of decades. There are ideological reasons to prefer open source as well, but its effectiveness as a development model has won over the pragmatists.
The goal of the Keylime project is to connect the features of Trusted Platform Modules (TPMs) and cloud computing. Keylime is a scalable trusted cloud key management system, providing an end-to-end solution for both bootstrapping hardware-rooted cryptographic identities for Infrastructure-as-a-Service (IaaS) nodes and for system-integrity monitoring those nodes via periodic attestation. Keylime extends the attestation capabilities of the TPM into the cloud, allowing tenants to verify that their applications, operating systems, and everything down to the hardware have not been tampered with.
A TPM (Trusted Platform Module) is a chip, present in most modern computers, that can perform various cryptographic statements in a tamper-proof fashion. In particular, through UEFI secure boot, a TPM can be used to verify at boot time that anything from the firmware up through the kernel and applications has not been modified from what the distributor originally shipped.
The world of multi-tenant bare metal cloud computing in the datacenter is increasingly important. With tenants being offered their own servers rather than locked-down VMs or compute services, the potential for innovation is much higher. Mass Open Cloud aims to offer a multi-tenant cloud where hardware would be shared between organizations, such as universities, with tenants able to access bare metal instances directly. Here’s how we propose to create a standardized architecture to provide a seamless elastic bare-metal experience for Mass Open Cloud and similar environments.
Our solution to the bare-metal-as-a-service problem combines two projects: Mass Open Cloud’s Malleable Metal as a Service (M2) and the Red Hat stewarded Foreman Project. Where M2 provides the means for provisioning servers, Foreman provides the orchestration and user interface.
In this video from the 2018 Red Hat Summit, Dan Walsh and Mrunal Patel lead a journey through a set of next generation tools for creating, deploying, and maintaining containers.
This journey covers tools such as CRI-O, Buildah, and Skopeo, which are being developed with other tools by Red Hat and the community into a complete toolchain for developing, operating, and maintaining Open Container Initiative (OCI)-compliant containers.
In another installment from the Red Hat Summit track from the Office of the CTO, this video is an informal discussion between Brandon Philips (previously CTO of CoreOS, acquired by Red Hat) and Clayton Coleman (Chief Engineer for OpenShift), interviewed by Steve Watt. They focus on Kubernetes as a platform of the future, identifying interesting trends in the open source ecosystem.
This discussion is a good example of the type of technologists that comprise the modern open source ecosystem, and epitomized by these three from Red Hat. Their backgrounds in real world development and operations combines with a genuine desire to help people that fuels their work in open source communities and product creation.
The challenges of maintaining persistent storage in environments that are anything but persistent should not be taken lightly. My recent conversation with Ceph founder Sage Weil certainly made that clear. Thus far, the conversation with Sage has highlighted key areas of focus for the Red Hat Storage team as they look to the horizon, including how storage plans are affected by:
In the last segment of our interview, Sage focused on technology that’s very much on the horizon: the emerging workloads. Specifically, how will storage work in a world where artificial intelligence and machine learning begins to shape software, hardware, and networking architecture?
As an industry we look to open source communities as our core innovation engine. At Red Hat we’re always monitoring, participating in, and even creating these open source communities. Here’s how you can garner some insight into where the industry, and Red Hat, might be going next.
It was not that long ago when organizations had in-house servers humming along running applications and storing data. Today, the opportunity afforded by containers means that applications can now live on a cloud platform (either public or private), or one of several available cloud platforms.
But while applications and microservices housed in stateless containers are easy to move from place to place (indeed, that’s a big part of the appeal of containers), the data the applications are accessing are stateful and very, very difficult to relocate while still maintaining consistency, latency, and throughput. This is one of the challenges faced by the Red Hat Storage team, and addressed by Sage Weil in his recent presentation at Red Hat Summit: maintaining data availability with acceptable latency when working with applications in multi-cloud and hybrid cloud environments.
When we look to the future of applications and platforms, we need to keep an eye on the solutions of the past.
That is one of the main theses of Stephanos Bacon, Sr. Director of Portfolio Strategy at Red Hat, in this video from Red Hat Summit 2018, “Clouds Today, Serverless Tomorrow: Your Future Apps and Platforms”:
In order to understand the present situation around the many choices of languages and platforms a developer faces, Stephanos briefly walks through a 25 year year journey of enterprise software development. This journey is one of a “continuous-though-forward-moving cycle”.
This cycle looks back at itself to learn and adapt from the past while moving forward in response to changing market imperatives. While we may need new solutions, we also reach back in time to find seemingly old solutions that address new classes of problems.
