HashiConf Global 2021 Opening Keynote
Get the latest updates on HashiCorp Boundary, Waypoint, and HCP Packer in this HashiConf Global 2021 opening keynote.
Both HashiCorp and Microsoft agree that the old paradigm of castle-and-moat security that relies on firewalls and VPNs is no longer enough for today’s hybrid and multi-cloud environments. In further continuation of our joint zero trust security vision, Microsoft and HashiCorp have announced that they will be working closely together on deeper integration between Boundary and Azure Active Directory, with Boundary currently available in the Azure app gallery.
Hear more about this news along with updates on HashiCorp Waypoint and the HashiCorp Cloud Platform. Join HashiCorp CEO Dave McJannet, Co-Founders Mitchell Hashimoto and Armon Dadgar, along with Susan Bohn, VP of Program Management at Microsoft for the opening keynote of HashiConf Global 2021.
»Agenda
0:00 - 6:52: The State of HashiCorp w/ CEO Dave McJannet
6:53 - 12:39: The Pillars of Zero Trust w/ Co-Founder Armon Dadgar
12:40 - 15:04: Update on HashiCorp Boundary w/ Co-Founder Armon Dadgar
15:05 - 21:13: Announcing a New Microsoft + HashiCorp Collaboration w/ Armon Dadgar and Susan Bohn, VP of Program Management at Microsoft
21:14 - 29:17: The State of HashiCorp Waypoint w/ Co-Founder Mitchell Hashimoto
29:19 - 32:28: Announcing the HCP Packer Public Beta w/ Co-Founder Mitchell Hashimoto
If you want to have a greater impact over the evolution of Boundary as it matures, join the Boundary Insider’s Program today.
»Transcript
Dave McJannet:
Welcome to HashiConf Global and our attendees joining us from all over the world. I'm here to give a quick company update.Then I will hand things over to Armon then Mitchell. A warm welcome from myself. But also from more than 1,500 employees from HashiCorp — most of whom work from home — across more than 790 cities in 20 different countries.
»HashiConf Agenda
Over the next couple of days, we're going to have well over 12,000 attendees join us, and they are coming from an amazing 100+ countries around the globe. You'll see that we've redesigned a few elements of this event to best allow our practitioners to engage with us and our products — but also each other.
You'll see that we've added hands-on labs in the HashiCorp zone to give practitioners hands-on experience and they’ll be able to interact with our products and employees on a much more one-to-one basis. As always, the sessions from this event will be available on-demand if you want to come back and watch something that you missed And they will be moved to our YouTube channel in the coming weeks.
As you've seen from us before, HashiCorp's built around working closely with three critical sets of constituents. We couldn't do what we do without all of you — practitioners, our ecosystem of partners, and then our customers that ultimately serve to enable them to adopt this cloud model for infrastructure. But the practitioners — you here in the audience — are the heart of what we do. You're the ones who download our products. You use them every day, and you give us the feedback that allows us to make those products better. In fact, in many instances, you contribute to the products yourselves.
»Key HashiCorp Numbers
This event and the participation around the globe is a testament to the power of that singular community that's aligned us around this consistent idea of enabling this common operating model for infrastructure. We saw over 100 million open source downloads in the last year alone, which is a staggering number to consider.
We know that works out to well over 10,000 different organizations around the globe. And, more interestingly to me, it's more than 75% of the Fortune 500. That means our products already underpin a huge percentage of the applications that we all use every day. And the community that makes this happen is manifested in well over 12,000 individuals who contributed code to us over the last 12 months, in the form of 280,000 code commits, which ultimately, in many instances, got incorporated into our products.
That's the power of a common community. Whether they're meeting virtually or, in a select few cases, in person, we now have over 36,000 HashiCorp user group members across more than 140 chapters in 50+ countries around the globe. A thank you to each of you who make our community the vibrant and supportive place that it is.
Our ecosystem of partners also plays an incredibly critical role. Ultimately, we're working most closely with the public cloud providers, for whom our products enable a consistent unwrap to the myriad of technologies they introduce each year.
»Partners and Partnerships
Our technology partners contribute and enable integrations to our products — to allow our products to connect their products to the cloud providers and beyond. And then, we partner with the global and regional system integrators and resellers who do the hard work of ensuring our customers are successful as they adopt this tech, which is relatively new to many of them.
All told, we have well over 1,400 Terraform providers in our Terraform registry alone, which speaks to the breadth of integrations provided by all of you to enable this common approach to infrastructure.
We have well over 700 unique partners, including 170 ISVs. These numbers continue to grow as we become mission-critical to our customers — but also increasingly integral to the entire software ecosystem. Thank you to each one of you for your collaboration and your partnership.
»Commercial Customers
Last but not least, thanks to our more than 2,100 commercial customers for the faith they place in us every day. We're proud to serve a hugely diverse set of organizations, including companies like the ones you see on the slide, General Motors, Anaplan, Pandora, Ubisoft, Comcast, Roblox, Wayfair, Petco, Barclays, and many more.
We serve small cloud native organizations at the very leading in edge of infrastructure, all the way up to the more traditional enterprises. In fact, today, over 315 of the Fortune 2,000 are HashiCorp commercial customers.
What's most interesting to me is that we're seeing the blueprints for how to run infrastructure pioneered — by and large — by the cloud native environments using the HashiCorp products to underpin their infrastructure automation, security automation, networking automation, and enabling that application delivery process that underpins the cloud operating model. That blueprint is actually making its way, almost intact to the global 2,000, and that's what we see each day.
»HashiCorp Cloud Platform
A huge focus for us over the past several years has been to make it easier and easier for you all to use our products in that provision, secure, connect, and run role that we play for everybody — ultimately to run that cloud operating model.
One way we're doing this is through the delivery of the HashiCorp Cloud Platform, which you'll see us refer to as HCP. HCP is our fully managed cloud platform for running any of our products. It helps organizations with resource and skills gaps. Improving operations and speeding up deployment time for our customers so they can spend more time focused on their applications than on their cloud native infrastructure.
So far, we've delivered HCP Consul, Vault, and Packer. Terraform Cloud was introduced late last year, and there's more to come, as you'll hear from Armon and Mitchell. We've already seen thousands and thousands of users get started with our cloud offerings in the very short time since we've launched them.
Several of the products, most notably HCP Consul and Vault, went GA this year, so it's still relatively recent. I'd encourage everybody to seek out the HCP-related content at HashiConf this week.
Thank you for joining us on this journey, which many of you have been on with us for quite some time. And thank you for joining us at this digital event. I'm going to hand things over to Armon now, who has a number of updates to announce related to HashiCorp's newest products and technologies. Armon, over to you.
Armon Dadgar:
Thank you so much, Dave, and welcome to HashiConf Day 1. I'm super excited for today. We're going to focus today on giving updates on our new emerging products, two of which we released this time last year at HashiConf — Boundary and Waypoint — and HCP Packer, which we announced over the summer.
»Zero Trust Security
As we dive in and talk about Boundary, to set the stage, I think one of the things we spend a lot of time as an industry now talking about is this transition to zero trust security.
It's clear there's been a shift in the modern threat landscape. We need to spend more time hardening the inside of our networks, and we're seeing over and over again these massive cybersecurity attacks. This is starting to spill over into the news coverage. We're seeing more of these breaches, and we're seeing things like the Biden executive order, mandating a shift over to zero trust. Clearly, there's a lot happening right now, and we're excited to think about the future of security.
One of the challenges when we talk about the traditional approach to security — which we refer to as castle and moat —, is what we really focus on securing the four walls of the datacenter and bringing all of our traffic over a well-defined drawbridge.
It was over that point we brought our firewalls, our web application filters, our various security approaches, to secure it and say, the outside is bad and untrusted, the inside is good and high trust.
The challenge we've seen with that model is it doesn't quite work. Our workloads are too dynamic. We have cloud infrastructure, and on-prem infrastructure, and people working from home, the network isn't clean and well-defined. There isn't a single point of traffic coming in and out. It's too hard to secure that perimeter. We need to move beyond that and think about hardening and securing the inside of our networks as well.
That's the heart of this transition to zero trust. Moving away from trusting our network to instead explicitly authenticating and authorizing all of our applications, our users, our systems, and access between them.
»Identity-Driven Controls
How do we make that happen? For us, there are four key pillars of enabling it.
»Human Identity
The first pillar of zero trust is establishing human identity. At the heart of that is a single sign-on for our users and a common user directory. There are many ways we can solve this. It might have been done with things like LDAP and Active Directory on-premises. Now it might be done with a cloud-based IDP like Okta, Ping, or Microsoft's Azure AD. So many different solutions there, but it's about this common user identity.
»Machine Identity
On the other side of that, is how do we think about machine identity? This is a relatively new problem, not one that we traditionally solved. This is where Vault sits. At the heart, we're trying to enable Vault to bring in application identity. Whether it's a traditional app running on-premises and it’s being brokered through active directory. Whether it's a cloud-native app and it’s using AWS or GCP or Azure's IM model. Or whether it's running on an application platform like Kubernetes.
Regardless of where the app is, Vault's there to enable a consistent approach to identity. Once we have that, we can extend that to things like secrets management or data protection. Join us later today. We're going to have a deep dive in on Vault and the roadmap there if you want to learn more.
»Machine-to-Machine Access
Once we have the first two, human identity and application identity, then the middle two pillars are about governing the access between systems. The first challenge is the machine-to-machine access problem. Our web server — as it connects to the database — how does it discover it? How do we secure that connection? That's where Consul sits. It’s allowing us to bring an identity-based approach to securing those machine-to-machine interactions. We have a lot more updates about Consul tomorrow, and I'll be excited to talk about them then.
»Human-to-Machine Access
The last pillar is about that human-to-machine access. How does a developer access a database system? How do we secure that? How do we make sure it's done based on identity even as our infrastructure's highly dynamic? That's the problem we set out to solve with Boundary, which we introduced last year.
If we talk about the traditional approach to having privileged access, it starts with a user. That user is then first connecting to, let's say, a VPN system or an SSH bastion. To do that, they need to have a username and password or a certificate or an SSH key, etc., that they need to manage.
Once you're on the network, you don't want the user to have access to everything. Traditionally you're going to apply a firewall or an IP-based set of controls to restrict what they have access to on the inside of the private network.
You might use a Privilege Access Management system. The user can get a credential — let's say a database password — or to session record, and have visibility in what they did to make sure no one's exfiltrating data or running commands they shouldn't.
Ultimately, the user gets access to the endpoint system. The challenge with this is there are many different systems a user has to interact with that are cludgy. There are many different controls that an administrator has to deal with to ensure that the system is secure.
And particularly, as our infrastructure becomes more dynamic, this setup becomes brittle. This was the challenge we looked to solve with Boundary. The idea is to simplify and collapse all three of those layers into one. So, a user doesn't have a separate set of credentials or username and password. They do a single sign-on with their existing identity provider. That identity provider then enables a logical rule where we can say, "Great, our developers have access to our web services," for example.
Boundary doesn't give the user direct access to the network. Instead, it will directly proxy back to whatever the host is, so we don't need another layer of firewall. We also don't need another layer of privilege access management. Boundary is establishing that session, managing and providing the credentials that the user needs — collapsing those three different systems into one.
»Boundary: One Year On
Over the last year, we invested heavily in Boundary, in maturing the tool since we first launched it. I wanted to give a preview — and a review in some sense — of what we've done in that last year.
»Richer Desktop UI
The first that I'm excited about is making the desktop UI much richer for end users. Now we have a desktop client for Mac, Windows, and Linux. It provides an intuitive and easy way for developers to log in, see what they have access to, double click, and initiate a connection into whatever system or target they need to access.
»OIDC Integration
At the same time, we've introduced OIDC integration. This makes it easier to integrate Vault and Boundary with any of your existing identity providers, such as Okta, Ping, Microsoft Azure AD. Now you can have that seamless, single sign-on experience for the end-user.
»Boundary and Vault Integration
We've also integrated Boundary and Vault. One of the challenges we often see is credentials living in multiple places — once for human users and in a different place for our machine-to-machine interaction. This enables all the credentials to live centrally within Vault — and Boundary broker access as needed within the context of a session.
As you initiate a connection, Boundary can fetch the credential and provide it to the user. It might be a static credential that we're brokering access to. But it might be a dynamic credential that Boundary is creating in time for that individual session.
This allows Boundary to use Vault to create that short-lived credential, just use it for one session, and when the user disconnects, talk to Vault and revoke it. This starts to move us to very ephemeral, short-lived credentials that minimize the risk of any exposure.
We're super excited about the traction the Boundary project is seeing. It's already been downloaded hundreds of thousands of times. It's being used by some of the world's largest organizations. And it's only been a year since we introduced it — so super excited about the traction. We also love hearing from our community. Whether that's on our Discus Forum, through GitHub, or seeing some of the social engagement, it's fun to see all the excitement around the project.
»Boundary Insiders Program
If you're excited about Boundary and you want to help us evolve the project over the next few years, we've created a program we call the Boundary Insiders Program. For folks who are on the bleeding edge of security and pushing the zero trust transformation, we want to hear from you. We want your feedback to continue to evolve the program — so please join that.
Boundary sits in this context of this larger effort from HashiCorp to think about zero trust security. As we do so, it's clear that we sit in an ecosystem of partners, and we work closely with our technology and cloud partners to make zero trust easy and more accessible.
»The Microsoft/HashiCorp Partnership
One of the most steadfast partners for us on this has been Microsoft. When we talk about the Microsoft partnership with HashiCorp, it spans a whole range of products. With Terraform, we have deep support with Azure, as well as Active Directory, through their MS Graph API. Throught the rich integrations around enabling an infrastructure as code way of interacting with different Microsoft products.
We've integrated Vault tightly with Azure and the identity model there, allowing applications to authenticate with Vault — allowing Vault to broker dynamic access to Azure systems.
We have a native HashiCorp Consul service on Azure. You can get a managed version of Consul and natively provided within the Azure platform. And we've enabled deep, single sign-on integration across all the products.
»Expanding Our Partnership with Microsoft
It's only logical that with Boundary, we also looked to Microsoft to drive a deeper integration and partnership for our joint users and customers. So, I'm super excited today to announce the expansion of our partnership with Microsoft.
Microsoft is a leading vendor in the enterprise identity space with their Azure AD product. So it was natural that we'd want Boundary to work very closely with that to enable seamless human-to-machine interaction. To talk more about this, I'm excited to introduce Sue Bohn from Microsoft to share a little bit more about what we're doing together. Over to you, Sue.
Sue Bohn:
Thank you, Armon. We're thrilled to collaborate with HashiCorp on providing secure remote access to hosts and critical systems across platforms and clouds. Hybrid and multi-cloud infrastructure are now the norm. In fact, in a recent survey we commissioned, 97% of IT decision-makers describe their environment as hybrid, and 91% use at least two public clouds.
With hybrid and multi-cloud environments as your foundation, any disruption can have devastating effects. Here at Microsoft, we're committed to help protect any customer environment regardless of the apps, clouds, or platforms they use. To protect these varied environments, it's imperative to have a strong identity foundation.
As the world's largest cloud identity service, Azure Active Directory has grown to process over 100 billion authentic creation requests per day. It protects over 425 million monthly active users across many different environments. Thousands of organizations trust Azure AD as their first line of defense against cyberattacks. And it has been essential to many organizations' zero trust strategy.
»Microsoft’s Perspective On Zero Trust
Let's talk a little bit more about zero trust. Microsoft shares the same philosophy as HashiCorp — that the old security paradigm that relies on firewalls and VPNs no longer applies. Today, there's no single network perimeter, no boundaries across pro-collaboration, plus, there's been an explosion of devices and applications.
We think of zero trust as a worldview and a security strategy, which has been put to good use — the increase of secure remote work during the pandemic. Zero trust replaces the assumption that everything behind the corporate firewall is safe with three simple principles: verify explicitly, use least privileged access and assume breach.
It requires validation at every step of the process. It means that all touchpoints in a system — identities, devices, and services — are verified before they're considered trustworthy. And it means that user access is limited only to the data, systems, and applications required for that role. By moving from a model that assumes trust to one that requires verification we can reduce the number and severity of security breaches.
Our partnership began with Terraform, leveraging Microsoft Graph to make it easier to manage Azure Active Directory resources, with infrastructure as code. We're continuing our strategic partnership with Boundary. And we're excited to provide organizations with streamlined zero trust access management to infrastructure resources while having improved visibility into session activity across platforms and datacenters.
»Azure AD and Boundary Integration
With Boundary and Azure Active Directory, customers can access any system from anywhere based on their Azure Active Directory user identity. Boundary will be accessible within the Azure AD app gallery, enabling developers to securely access hosts and services in hybrid and multi-cloud environments.
Our two teams are currently working on deeper integration between Boundary and Azure Active Directory to offer a seamless, automated onboarding of an Azure tenants' identities, targets, roles, and permissions to a Boundary environment.
In the future, we'll be working together to access Vault using Azure Active Directory. Together, we're offering solutions and frameworks for zero trust without adversely impacting productivity in today's hybrid and multi-cloud world. Back to you, Armon.
Armon Dadgar:
Thank you, Sue. I'm so excited for this partnership. I know it's early days, but I'm very, very excited for what we can do by bringing these products closer together and making zero trust more accessible for our joint users.
For people interested in checking this out, we're going to have a breakout session tomorrow, and you can learn more about how you can be using Boundary with Azure AD right away. And now I'm super excited to welcome to the stage Mitchell Hashimoto, Co-Founder of HashiCorp, to give us the rest of today's product update session. Welcome, Mitchell.
Mitchell Hashimoto:
Thanks, Armon. Next up, I want to talk about Waypoint. A year ago, we announced HashiCorp Waypoint, an open source project that simplifies how developers build, deploy and release applications across any platform.
»Waypoint Recap
When we announced Waypoint, we shared this core thesis for the project which is that developers want to deploy. We still have that thesis today, driving the project. Developers today have a vast variety of tools at their fingertips, but the deployment workflow is still complex.
Let's start with just the release platform itself and take a look at Kubernetes as an example. The main challenge facing developers with Kubernetes is how much they need to interact with Kubernetes to deploy an application.
For example, just to deploy a simple two-tier web application, a developer needs to interact with almost a dozen Kubernetes core objects, such as pods, services, or higher-level components, such as deployments, stateful sets, etc..
A developer needs to be aware of what they are, how to configure them and set them all up to make everything work. And the platform is just one part of the end-to-end workflow to get an application from source code into production.
The other part is the workflows around all the other stages, such as build, deploy, release management, etc. Operators generally build these automated workflows with many tools to bring some consistency and velocity to the process.
However, due to the heterogeneity of the workloads, the applications, and their platforms, all of these end up tightly coupled to the environment or a particular ecosystem. This leads to inflexible workflows, limited shared knowledge, or an inconsistent developer experience, especially if new technologies are introduced into the stack.
We created Waypoint exactly to solve these two challenges, which are two sides of the same coin. Waypoint aims to solve the deployment challenge by enabling developers to get their applications from development to production in a single configuration file with a unified workflow.
»Waypoint Highlights
It's been a year since we announced Waypoint, and the project has evolved in many ways. I want to start by sharing a few highlights over the past year — and the past few releases — and then offer some insight into where the project is headed from there.
»Variables Templating
First, we introduced variables templating and other key features aimed at improving the Waypoint configuration file to enable developers and operators to create more reusable dynamic Waypoint configurations. For example, we can now dynamically template docker files and bring in elements that are dependent on the environment — staging, production, etc. We can also define input variables in the Waypoint configuration files that could be used to parameterize the configuration file for reuse.
»Native GitOps Workflow Support
In addition to the configuration file, we built a lot of new features directly into the server and core workflow itself. One of the biggest ones is Native GitOps workflow support. This is also the recommended way to use Waypoint today. Waypoint can be configured to automatically update applications as changes are pushed to a Git repository.
»Post-Deploy
Finally, we also made some big changes into the post-deploy world of Waypoint. We built a feature to enable near real-time visibility into deployments and their health status. This allows developers and operators to easily monitor the applications and resources through staging and production environments.
»Waypoint 0.6
Over the past year, we observed many users are primarily looking for ways to simplify the complexity of Kubernetes in their deployment environments. This is one of the most popular deployment platforms, and we see this as the most popular place to simplify. Therefore, in this release — and over the next few releases — we're doubling down on Waypoint's Kubernetes focus, and we have a lot of improvements there.
Our goal with Waypoint is to empower operators to deliver a PaaS-like experience for Kubernetes and to be able to scale that experience consistently across other platforms, such as ECS, Nomad, Serverless, and more.
Towards these new goals, we're pleased to unveil Waypoint 0.6. This release ships many features that fundamentally improve Kubernetes workflows, and I want to share some of them with you now.
»Helm-Based Install
The first starts at the installation of Waypoint. We now support a Helm-based install for Waypoint. This is the recommended way to install Waypoint if you're a Kubernetes user. Now, if you use Kubernetes, you could use Helm and get a fully production-ready Waypoint server on your cluster.
»Helm-Based Deploy
Continuing the theme of Helm, but on a separate end, we now support Helm as a way to deploy your applications. If your organization already writes Helm charts — or already has applications with a number of Helm charts — you could bring them into Waypoint and begin deploying right away without rewriting any of that.
»Runner-based Architecture
We also switched with Waypoint. 0.6 into utilizing a runner-based architecture, where all operations like builds, deploys, etc., happen on on-demand pods that are launched in your Kubernetes cluster.
So these are fully isolated per operation, and you could customize the image that runs these operations. With that, you could have much better security and much better customizability over all your operations. And whether it's Kubernetes, ECS, or any other platform, Waypoint provides a workflow that allows users to better describe the necessary changes for each environment.
For example, here, we're setting a different configuration variable for the database URL, whether it's staging or production — and you could do this across any application configuration. In future versions, we'll continue to introduce environment-specific features into Waypoint.
»Kubernetes Workflow Improvements
Now, let's look at a few examples of how the changes we made in 0.6 improve the Kubernetes workflow. Kubernetes users today need to adopt multiple tools to define and update resources — or at least be aware that they exist. For example, you have to know Docker exists, how to write a Docker file. You have to know about KubeCTL, how to execute that, to look at resource health.
If you write Helm charts or use something like Customize to deploy your applications, you need to be able to know how to write and use both those tools. But with Waypoint, we could still leverage many of these tools but represent them within a single configuration file and invoke them within a single workflow.
Put another way, many users today need to manage multiple sets of configuration files for different environments and invoke different tools. This becomes increasingly difficult over time, especially as new tools are introduced. But with Waypoint, they can manage and promote resources across environments more efficiently and consistently, with a single configuration file and a single workflow.
»Waypoint Goals and Priorities
First, we want to enable a consistent PaaS experience for Kubernetes, ECS, and other platforms.
Next, we want to build a tool that solves the end-to-end workflow, from development into production, to simplify the whole process. We're not just focused on the one step of deploying to a platform.
We want to keep the configuration application-centric to hide some of the infrastructure complexity from developers and give platform builders and operators more flexibility to introduce new tools into the stack.
And last, we want all of this to be highly extensible. Whether you're doing a build, deploy, or release — all of that tooling, what you use, what platform you're going to — all of that is plugin oriented, and you could write custom plugins yourself.
This was a brief overview of Waypoint 0.6. If you want to watch a full product demo showcasing a real product being adopted into Waypoint on Kubernetes, please see the breakout session later today. Or, if you want to get started, go to the Waypoint website, download it, and get started.
Next, I want to talk about the HashiCorp Cloud Platform or HCP. HCP’s a big deal for us. We're investing in it constantly. And you'll continuously see a lot of exciting new services from us. One service we announced in June is HCP Packer.
»HCP Packer
We designed HCP Packer to solve a specific problem in image management. We noticed that it's easy to build images in Packer, and it's easy to consume images. But there's a gap in the middle where it's difficult to know what images exist, how they're versioned, what changes exist, whether it's safe to use one or not, etc. This is the problem that we're addressing with HCP Packer.
Firstly, that this service aims to offer an artifact registry hosted on HCP that addresses this gap. Now the Packer builds still happen — wherever they're happening today — on your local machine, within a CI environment, etc.
HCP Packer doesn't aim to be Packer in the cloud. Instead, after the Packer build succeeds, metadata about that artifact is sent to HCP Packer and stored in the artifact registry. This registry can then be used with any modern toolchain, but it's especially useful if you use it with Terraform Cloud.
In recent months, since we initially announced this project, we launched the private beta, and we've received a lot of great feedback from those private beta users. On top of that, we're excited now to move that service to the next phase of availability, which is the public beta.
»Public Beta Now Available
What you should do now is log in to your HCP portal, and you'll immediately see the new Packer service in your account. The beta is free to use. To try out our other services, or if you don't have an HCP account already, please sign up for one at cloud@hashicorp.com.
For HCP Packer, the hosting of image metadata for your workflows is just the first step in addressing a more extensive set of challenges that we see. The cloud-enabled registry could also simplify tasks like remediation, enforced security checks, and image deployment.
So, for example, with remediation, we could keep images up to date with remediation workflows, revoke images, ranges of images, etc.
