Distributing Supply Chain Artifacts with OCI & ORAS Artifacts - Steve Lasker, Microsoft

Summary

In this engaging talk, Steve Lasker from Microsoft delves into the intricacies of distributing supply chain artifacts using OCI (Open Container Initiative) and ORAS (OCI Registry As Storage). He emphasizes the growing need for efficient storage solutions given the increasing diversity of supply chain artifacts, ranging from containers to packages and IoT deployments. Steve explains how leveraging existing registries, like those for Docker, can optimize the storage and distribution process, avoiding the need for new infrastructure. The session covers best practices for artifact distribution, considering security, compliance, and the challenges of managing multiple artifact types across various cloud providers.

Highlights

• Discover how Steve Lasker explores the evolution of storage solutions for supply chain artifacts. 📦
• Learn about the role of OCI and ORAS in modernizing artifact distribution. 🌐
• Unpack the significance of registries in managing diverse artifact types efficiently. 📊
• Understand the importance of security and compliance in artifact management. 🔒
• See how leveraging existing infrastructure can prevent the creation of redundant storage solutions. ⚙️

Key Takeaways

• OCI and ORAS offer robust solutions for distributing diverse supply chain artifacts, reducing infrastructure overhead. ⚡
• Registries are the backbone of efficient artifact management, supporting multiple artifact types and ensuring security. 🔑
• Proper artifact distribution includes maintaining up-to-date, original, and compliance-ready copies close to deployment locations. 🌍

Overview

Steve Lasker from Microsoft dives deep into the future of distributing supply chain artifacts with an introduction to OCI and ORAS. These frameworks are stepping stones for organizations juggling growing lists of artifacts like containers, S-bombs, or IoT deployments. By capitalizing on existing registries, companies can manage these artifacts more seamlessly, avoiding the hassle of setting up new storage solutions every time a new type emerges.

With an engaging narrative, Steve elaborates on the best practices for artifact storage and distribution, stressing that security and geo-redundancy are essential to ensuring both efficiency and integrity. He uses quirky analogies like comparing software registries to household refrigerators, underscoring the importance of readily accessible, reliable, and trusted storage solutions.

As Steve unravels the complexities, he makes a persuasive case for standardizing the process of accessing related data within registries. Through a series of informative examples, he highlights how innovations like the OCI distribution spec have turned traditional registries into comprehensive artifact management solutions, enabling multi-cloud environments to operate without friction.

Distributing Supply Chain Artifacts with OCI & ORAS Artifacts - Steve Lasker, Microsoft Transcription

• 00:00 - 00:30 well hello everybody it's getting towards the end of the week hopefully everybody's starting to think about how they're going to enjoy wonderful valencia so i'm here to talk about distributing supply chain artifacts anybody thinking about security these days right kind of a little bit of a focus um there's lots of new supply chain artifacts where are we going to store them how are you going to handle them what do we do with these things so i'm steve lasker i'm a pm architect in azure
• 00:30 - 01:00 and this is an area that i've been spending a lot of time thinking about for how we store and distribute them and something we've been working on for a while actually so i'll kind of talk about what we've been thinking about and how it's been evolving so lots of supply chain artifacts where are you going to store them how are you going to distribute them it turns out the what matters because of some of the best practices for how we think about just to distribute and deploy these and we'll talk a little bit about should
• 01:00 - 01:30 we be building new services or should we invest and extend some of the existing services that you're all using already so i'll spend a little time talking about this elegance and evolution of registries which will put context to the whole whole thing of oci and aura's artifacts so there's lots of them oh my it's just every day there's a new artifact type that's coming out whether it's a new s-bomb format or claims or attestations there's just lots of different
• 01:30 - 02:00 types that are applying to the software already thinking about so we think about containers but there's packages there's loose binaries turns out there's iot deployments that we should be thinking about from the killer cars that can be taken over to the medical devices that are in the people that got hit by the killer cars right these are all components that we should be thinking about of how do we have supply chain artifacts around these new types or new types
• 02:00 - 02:30 around the existing things we're already deploying but it also applies to our vms that are under the covers for all of our containers that we're running right this is not a new problem it's just a matter of how do we think about it across the spectrum of software and hardware quite frankly so as we started this effort several years ago a lot of these formats didn't exist they continue to pop up so how can we think about associating all of those with the type of software
• 02:30 - 03:00 we're building so where will you store them does it matter do you need to distribute them or if i just make them available on a website everything's good and by the way what's the life cycle of these so we'll spend a little time talking about that now we spend some time thinking about the best practices for how we're going to consume public content or consume software in general on your way here
• 03:00 - 03:30 you've made some software available you might have you know built a new image or whatever you were working on as you're leaving the cluster needs to scale should that cluster be pulling across the internet and a thousand different types of connections from docker hub or some other public registries like elastic how many of you have a refrigerator in your house why you can go to the store and get fresher milk every day right what is it going to be in stock right we go to the refrigerator in our
• 03:30 - 04:00 house in our hotel room because it's right there it's faster it's reliable because it's there right right there now i keep on updating it i keep on replenishing it it's the same model with our production notes we don't want to be reaching out across the public internet or outside of our control for content that the connection might be bad or it might have gotten updated let's not forget solar winds the exploit there was a software update
• 04:00 - 04:30 lots of updates are well intended and break us because everything that changes is a change of some sort so we want to make sure that we've got a tested copy of the software we depend on in a location we can depend upon and then have a constant stream of updates that could come in after we've tested them to apply so the content the concept here is basically we want to keep a copy of the stuff we depend on
• 04:30 - 05:00 as close as possible even in the same region of your deployments if you're deploying in us and uk and you know australia and asia you want to keep copies everywhere that you're deploying from well shouldn't we have that other supply chain artifacts with it as well so we want to ship all of that software together so it as i'm trying to do verification whether i should be deploying this thing because i'm making a decision based on the s-bomb or the git bomb or any of the other claims of
• 05:00 - 05:30 details we want to make sure that with the software itself now we have automated builds right we probably build more than once a week these days or once a month it's probably multiple times a day maybe even every get commit for every one of those builds how many do you test how many tests succeed and how much do you actually deploy for each one of those are you generating all the new supply chain artifacts
• 05:30 - 06:00 right so you start to think about wow this is starting to get to be a lot what about all that non-deployed content there's some liabilities there's assets and liabilities here but i'm not just talking about the storage costs of this that's the least of the problems all that software there's vulnerabilities everywhere but do you care if you have a vulnerability in software you built you never deployed does it
• 06:00 - 06:30 matter the scanner doesn't know any different the alerts don't know any different so we want to get rid of the stuff we don't care about but there's still a lot of stuff that we do care about you've all the software that we've deployed that's a subset but we still need to keep track of that as well how many of you have compliance requirements that for any software you deployed you need to keep for some amount of time 18 months tends to be the magic number
• 06:30 - 07:00 for all of that software you've deployed but it's not deployed now are you scanning it well you probably should because you want to know if there was any exploits do you patch the archive software because you've got an alert you're supposed to go patch it if i'm patching the archive software which i'm keeping for compliance then it's not the software i deployed so there's just lots of complexity here as you want to move your deployed
• 07:00 - 07:30 software that's that was now archived you want to keep that in a separate place you're going to need all of those supply chain artifacts to travel with it as well what was the s-bomb at the time hey i've got a vulnerability now why did you deploy that thing well in january when i deployed it look the scanned result didn't know about it that's why we deployed it the scans didn't show that there was an exploit in it until a month after it was taken out of production so it actually wasn't a problem
• 07:30 - 08:00 but you need to be able to keep track of all these things now is everything publicly accessible by everybody right it's one thing to have oss software that's available but we consume oss in software that we either ship with intellectual property that we don't make publicly available to the ingredients or it's internal within our firewalls within our companies that we need to keep what's the scoping of access to all of that
• 08:00 - 08:30 does everybody have equal access to all things does everybody get create update and delete rights or we should we just trust everybody kind of defeats the purpose of you know well actually if we trusted everybody that we wouldn't have to worry about security but of course that's not the case and then what about just listing the information out what about the metadata on it right all these are the things that we think about the more the days day next around what these storage services have to provide
• 08:30 - 09:00 and what about all the idi's for production capabilities right these there needs to be geo-replicated into multiple regions within a region there are available uh multiple availability zones this is the expectations that are put on a cloud providers for these services how do you promote that content how many of your customers are multi-cloud or you are multi-cloud will this work across multiple clouds or on-prem and when stuff goes wrong how do i think
• 09:00 - 09:30 about the diagnostics and all the troubleshooting so you kind of get the pattern here is in in firewalls right we talked about how this software needs to be able to be available within a v-net because all of our customers want their security that they had on-prem in the cloud no public access lock it down so these are all the requirements that keep on coming up on these various storage services oh and then by the way who's going to support these things
• 09:30 - 10:00 so running a storage service is complex right we start with some blob storage we add some rest apis for discoverability we put authentication on it there's some caching for the multiple requests for the same thing there's some kind of support there's integrity and signing that's available on all of these things and all these other capabilities keep on coming up so it turns out like we should you know it is complex for all of these and all of the supply chain artifacts
• 10:00 - 10:30 are going to have the same checkboxes for requirements so as we're looking all of this should we building new services for these things do i need a new spdx service do i need a new cyclone dx service or an s-bom service or a scan result service the idea is that we'd want to be able to leverage what we already have so that's kind of the setup here is which one should we invest in so git turns out pretty popular
• 10:30 - 11:00 very tailored towards your build environments right it's optimized for developers making changes and tracking those changes it is not optimized for production deployments we have lots of things trying to pull from at the same time and we've seen that with some of the various technologies that are trying to do more git-based deployments there's lots of existing package managers and most of them are underfunded they just don't have the capabilities we're always trying to get them you know
• 11:00 - 11:30 to improve but just it's not the critical business sure we could use raw storage accounts which is underneath all that but it's not robust enough and then we can get to various isv products but then we're starting to compete for things and this is not the place that we're trying to compete the package managers and the storage services and registries they're lost leaders they're there to enable the rest of the workloads which brings us
• 11:30 - 12:00 to what we've been doing under the oci distribution spec is leveraging that capabilities to which every one of your cloud providers have it you have them on friend if you're kubecon i'm sure you have a registry somewhere at least one how about we extend into that infrastructure so let's take a little bit of the elegance of registries because it turns out it's actually pretty well designed so let's walk through a couple of pieces to it so first of all if you say docker run
• 12:00 - 12:30 and you're doing anything other than docker hub there's going to be some registry url that is the endpoint it could be the login endpoint the rest endpoint the registry name all kind of it's synonymous the idea is there is some address for where you find this thing it's kind of a little weird that registries are the only package managers that you have the addressability in it right like every other package manager it's a config option so that's a
• 12:30 - 13:00 different effort we're trying to make that a little easier so you can promote these things and it's a configuration for the registry there's some name space where your stuff is stuffed into and depending on the particular registry it could be one two or n levels deep it's really just a path with magic slashes in it then we finally get to the actual image and there's a version turns out it doesn't actually need to be
• 13:00 - 13:30 an image it could just be what we call an artifact so what's under the covers for all of this that net monitor v1 image is backed by a manifest a manifest is just a json document that has some descriptive information about it it's intentionally lightweight and we'll talk about that a little bit more then there's
• 13:30 - 14:00 one or more collections of content the actual content that makes it up those are blobs it's all stored in some kind of blob storage usually some of the lightweight registries that are on-prem or you know on you know iot snares they might be using regular files for storage but typically there's some kind of blob storage and there's this rest api we talked about if we map that into a registry the manifests there's a lot of them they're stored
• 14:00 - 14:30 and the blobs are in blob storage and now we're starting to see how this is framed together if i walk through what a docker pole looks like this gets a little interesting too so i have the client here on the left and it says hey docker pull this net monitor image from this registry the client calls that registry and says hey i need this thing can you tell me about this thing sure let me give you back a manifest
• 14:30 - 15:00 the manifest is meant to be extremely lightweight because i want to be able to pull it often not as is massively minimal information as possible until it manifests because it's going to give me some metadata including the list of blobs i might even have one of those blobs on disk already because i already pulled the base layer for some other image all right so i've already got some of that information i really don't want more information to come to the manifest than possible it now says
• 15:00 - 15:30 hey um from that list of layers or blobs that's in that manifest i already have this one but i don't have the other one hey registry can you give me a url for this blob and this is another interesting part about the way the registries work even though the registry endpoint in this case is registrywabbitnetworks.io the response to the request for the id for layer 2 can be a completely different url that's a protocol that's set up
• 15:30 - 16:00 that's how we're able to enable that's how we enable cdns that can be serving the blob content from different endpoints it's how we do regional endpoints right it allows us to kind of there's a negotiation there it says i know you asked for rabbit networks registry rabbit networks io when i'm going to give you the content it actually can be a different endpoint so those are things just to be aware of when you're configuring firewall rules too as to look what your cloud provider is doing or your registry is doing so then it finally says hey here's the
• 16:00 - 16:30 url and the client goes okay great let me go pull them and i might pull them concurrently and of course this is the model we see we see that in the docker model we see the layers being expanded and once all those layers are there it goes hey i'm done here's the container register the container image and off it goes so if we look at what's in that manifest there's this collection of blobs they're called layers in the container image format
• 16:30 - 17:00 there's a collection of layers and there's this config object the config object is just another layer it's just another blob just a specialized one everything in a registry is stored as a descriptor which is nothing more than the type the hash and a checksum and the hash is the unique identifier and then there's some additional metadata which we'd love to do more with
• 17:00 - 17:30 uh this is like we think what people are using labels for this is what annotations were intended for we're hopeful that as we can start indexing these more that they'll actually be a nice circle that'll come around and go like well i can actually do something with them so maybe i'll produce more annotations now the files the blobs are really just a pre-structured way to kind of segment stuff it's really optimized around that shared content
• 17:30 - 18:00 but it's really no different than what your disk subsystems do when they were slower and we had these defragmenter things and they were fun to watch the little bits going around it's just a way to chunk up the files it just they're pre-allocated so a manifest is an artifact that's the way to kind of think about it what when a manifest is you submitted it is that net monitor v1 image the blobs are the content that make it up and it turns out there's actually
• 18:00 - 18:30 several manifest types that are in registries there's the one that's probably the most popular because if you've done if you're doing docker build that's what the docker manifest is it's the original one when it was submitted to oci there was a little bit of reformatting of it to make it a little more vendor-neutral and standard so that's the oci manifest same functionality if you have multi-arc images whether it be windows and linux or arm or whatever there's a another manifest list that's
• 18:30 - 19:00 basically says here's the separate individual manifest for arm linux windows and so forth but you can associate it with a single tag it's a nice little way to kind of get an abstraction there and then the oci index is the multi-arc version of that but there could be more so we'll talk about that let's first talk about tags because this is another aspect of it when you push something to a registry you're pushing
• 19:00 - 19:30 it as a tag usually the net monitor v1 image that's fine if i want to reuse that tag there's another manifest and potentially more blobs that get uploaded and this synthetic thing over here that you've called the tag is pointed at the new manifest that old manifest is still there it's just called an untagged manifest is usually the terminology and you might even set up that automatically delete untag manifest as a thing but there's a virtual concept of a tag
• 19:30 - 20:00 and it has a pointer that can float so recapping manifesto artifacts blogs the content we can secure them in namespaces all the content has unique identifiers which is really cool if you're pushing from two regions to the same registry we can easily handle there's no conflicts we talk about the tags or pointers and the artifacts in a registry can be from a k to multiple gigabyte
• 20:00 - 20:30 machine learning folks man you guys got some really big images it is pretty amazing how you stretch the extent of what a registry is capable of so as i've gone through this is there anything really unique around a container image in this in this flow that we just walked through it's pretty generically useful so i'll take you through a little journey on how we wound up doing this generic model so when we this was back in 2018 we're
• 20:30 - 21:00 trying to figure out how to make helm available within registries because it's a great way to deploy why not use the registry for it so we started going down this azacr helm repo ad and before we could even and it worked and mapped out pretty well but it was unique to azure like yeah okay but as we started we didn't even get finished and cnab was becoming a thing and singularity was saying like we
• 21:00 - 21:30 really don't want to host our own registry can we just get this working in the existing registries we don't want to run yet another storage service so we just kept on going down this list and we're like az acr as the ac are this the azure that's like this is not sustainable so we basically said all right let's invert this model how do we get the helm team who actually worked for azure at the time to want to build this into the helm client it only makes sense if it's going to work across all cloud providers
• 21:30 - 22:00 so what we did is we went back and said what if we leveraged that same infrastructure and generalized it so you can store helm charts in oci registries work in azure aws google on-prem wherever any place has a registry it should just work now all of a sudden it makes sense for the helm team and the terraform team and all these other teams to say well why should i create my own registry why don't i leverage those ones there it'll work across all cloud providers
• 22:00 - 22:30 so that was the evolution from container registries to becoming these artifact registries and all we did was basically relax some strings that were in the registries for how these things were mapped so we were able to say not yet in another storage service so that was kind of the evolution there now all these things can be stored in them and it turns out that you can it's so generically useful that we've actually done a bunch of prototypes where a lot of the package managers can be
• 22:30 - 23:00 stored in them as well but that's a whole nother thing okay so oci artifacts was about storing other individual things like helm like oppa like singularity like all these different and things we don't even know about that's the beauty of this like there's so many different types now being stored within companies and shared across projects what if i want to be able to associate other things with my existing one like how do i associate an s-bomb
• 23:00 - 23:30 with my net monitor image how do i create a relationship between those because when you look at your deployment chart all you know is net monitor v1 right nginx 1.12.6 what we want to be able to do is say hey based on that thing well first of all is it signed great can i attest to whether it you know it's
• 23:30 - 24:00 signed by entity i trust and how now i can go back and say hey by the way can you give me the s-bomb for this thing can you give me the list of scan results what is this current revocation status so when we started down this work we originally started this reference type stuff with uh with notary because we wanted to be able to associate detached signatures turns out that infrastructure is available for all kinds of different types so
• 24:00 - 24:30 how can we generalize from individuals to enabling how do i find other things based on that same name i don't want to change the tag or digest because that's what's locked in my deployment file don't mess with that like that's what i know but i want to discover related things i want to filter on those related things i might want to sort them because my scan results i do a lot of so i can't i don't have just one i want the latest or maybe i want the first to know what
• 24:30 - 25:00 it was originally scanned as oh and then because we talked about the life cycle if i want to delete the stuff that was never deployed i want to get rid of all of the s-bombs and scan results and all the other stuff because that's all that's gone i never deployed it but get it out of my system if i want to copy it to an archive location because i need to keep it for 18 months i want all those things to go with it as well right i don't want to have to correlate 12 different storage systems to figure
• 25:00 - 25:30 out where is all this content that i either need to save or delete so that leads us to the evolution does everything have to be a brand new service or can we invest in the existing servers that have all those idi's that i don't want to have to think about and you as users don't want to have to configure so we have a registry that can store all sorts of stuff what if you could ask the registry what else it has related to that thing
• 25:30 - 26:00 so we have this project called auras ocr registry of storage and i can say from a client perspective he discover what's related to the net monitor image and now the results can come back and say hey here's some signatures here's a bunch of scan results here's two different uh s-bomb formats and a git bomb
• 26:00 - 26:30 like i can hang all of those off my net monitor image i could even filter maybe i only want the scan results well there's three of them well i can order them by date descending or ascending and i can also say just give me the top one right that would be kind of cool let's show let's dig into how we can do this today so i've got um just a copy of
• 26:30 - 27:00 distribution actually a version of distribution that's got this functionality in it usually i start with a container image but what i want to show is it doesn't have to be a container image so at microsoft we have to abide by the us executive order for providing s-bombs and claims and details not just on the software we ship like office and other things but on the services that we run if we run office 365 we're not going to
• 27:00 - 27:30 host the office 365 service as a container but we do want to provide s-bombs for it so here i'm using the webbit networks company and they have this network monitor service that they run and they're going to have let's just call it the 2022 q1 m1 version that we're just going to create an arbitrarily named thing in the registry to make a reference to so i just created some json document no big deal i'm going to push this to the registry
• 27:30 - 28:00 using auras now this is the original oci artifact stuff we did a couple years ago all i'm doing is saying push localhost 5000 that's the registry and then the namespace is services and then the artifact is net monitor and i've got a version associated with it the manifest config thing that's again that's how we did ocr artifacts the first version just there's a way to have a type in there so i said it's an
• 28:00 - 28:30 application json just made up a type and then the service.json is the stub it's just that little file that just represents something so there is if i want to find some information about the service whatever you want to make really the main thing that i'm trying to do is just create a reference that tag now let's say i have an s-bomb i've got a very fancy s-bomb here it says i think it says it's good so it's just version whatever
• 28:30 - 29:00 it might be 200 megabytes long some of our s bombs for some of our services are huge right so we need something that can scale from very small to very large so i have an s bomb i want to push it to the registry and associate it with that net monitor 2022 q1m1 service because that's the thing i know i know of office 365 you know some version i know of the net
• 29:00 - 29:30 monitor service you know this version and now what's interesting is now i can start saying show me what's related to that service so i now have an s-bomb i've called it the s-bomb example right i know of the net monitor service i don't know what the identifier is for the s-bomb but i know my service name i know the software i'm looking for
• 29:30 - 30:00 let's say i want to add some claims we'll make this a little fancy here wait is that the one i did yeah so i've got some claims stop with the paste all right we'll do it there let's say that it conforms to some sdf compliance again i've got some document i want to make it available for people that are looking for the information on the service i'm going to push this one also as a reference so push
• 30:00 - 30:30 to the repo basically it's push the claims example that's the type think of it as like the file extension the dot you know the dot json file the dot steve file whatever there's a type i'm taking the claims.json file and i'm just pushing it up and the subject the thing it's associating with is that net monitor image did it wait did i push it yes i do sorry
• 30:30 - 31:00 i might have some additional annotations so this is what i talk about annotations would be really cool do you know the end of life for software when you build it you think you do usually don't it changes it turns out it might be more useful you might have to extend it you don't know what the next version i originally had m1 i think was the version i had up there turns out the replacement
• 31:00 - 31:30 m2 turned out not to be so good so we're going to say the new version of this software if somebody's looking for an update is actually m 3.1 so i can if i can add new information to the existing information that's in the registry that i can improve it over time right i can start to add more information so again i'm just going to push this again it's just this one says what is the artifact type is i just call this
• 31:30 - 32:00 artifact annotations and same subject right i keep on going back and saying i'm adding more information to that specific version of the net monitor image but notice there's no file here that was the interesting part and again if i just look at the tree of information let's just make this a little easier i'm starting to grow a pretty rich graph
• 32:00 - 32:30 of information that if i'm building all this in my build system i can associate them all together if i want to get something out this one we can do some better usability on this is where we are right now we're using the auras discover command i'm filtering by the artifact type of claims because that's the one and i'm just doing some parsing out of it says hey give me the first one the first entry out and give me the digest of it because everything's got a unique digest
• 32:30 - 33:00 and then i can say or as pull and now it'll pull into a download directory because i want to get it out of the same directory i just created it and i've given it the reference right because everything in the registry has a unique reference and if i were to now take a look at the output surprise surprise i was able to round trip that information back out of the registry i was able to pull just the
• 33:00 - 33:30 claims file i didn't have to pull all the other stuff i said hey the net monitor reference by the way i went to claims for it now here's where it gets really cool i've used several different tools i had an sp i had an s-bom tool maybe it's spd-x maybe it's cyclone dx i had a claims tool i had some annotations that i added to it if you're trying to copy the files from
• 33:30 - 34:00 one folder to another on your computer do you open up powerpoint and visual studio code or some other tool like adobe illustrator or whatever you use the file system api you say copy from here to here it doesn't care what the type is because we've set up this relationship with the objects in the registry i can literally go hey copy this from point a to point b and take the entire graph copy from services net monitor to web networks net monitor could be a
• 34:00 - 34:30 completely different registry and now if i look at the destination i got the same graph but it's at the other end that's kind of what's powerful by saying hey the registries now know about references i can copy all of that with me and i can now this is the content i need to archive this was the thing that was deployed it's no longer deployed let me archive this and keep it for 18 months and maybe one of the annotations is you can delete this 18 months from today
• 34:30 - 35:00 so that's the model that we've been kind of focused on check on time here um so it turns out registries already support manifests we're just adding another manifest type it's totally within the spec to add another manifest type this is how index got added the new manifest just says look it's a new type that's
• 35:00 - 35:30 the the media type says this is the new schema [Music] the we've taken the hack we did in oci artifacts v you know the original one because that's the way we just took the config media type and we surfaced it as a first class object a property so we can do the filtering by we've taken the layers and we've named it the blobs because layers are unique to containers turns out blobs are pretty generic if you really really really really need a config object
• 35:30 - 36:00 there's a media type just stuff it in the blobs collection and call it the same config object so you can still get it out it turns out most of them don't need uh configs the subject is the really the magic piece the subject is the thing that says hey this s-bomb is related to the net monitor image or the the service the goofy service reference that i created that's the back pointer it's very similar to how tags work tags there's no document
• 36:00 - 36:30 it's something that we cache or index but index is a loaded word it's something in the registry we store it in a database that says these things are related but there's no document that gets out of sync so we can do things like annotations because there's no blobs required right i can just set up hey here's just a new annotation now to get things back out there's the gazentas and the gazelletas if i'm
• 36:30 - 37:00 putting new manifests in with the subject property we index that information so when i call this new referrers api it's it's the opposite i call an api to get the content and i have another api that says i want the related objects to that net monitor image so it just returns a list of descriptors with the artifact type so i can decide whether i actually want the signature or the s-bomb that's how the filtering
• 37:00 - 37:30 works so just kind of going back this is actually originally what we you know we did for the notary work is we wanted to make sure that we can sign stuff without changing the original digest it turns out we want to be able to add s-bombs without changing the original digest we want to keep them alongside so we can copy them and we can pull them independently just like when you go to the airport you don't walk through with your your
• 37:30 - 38:00 passport you give your passport through the hole and if they like you and they approve you because they you weren't revoked then they download the rest to you through uh the security checkpoint or onto the node uh let's see what else that's basically it so there's a couple of links here for how we've been doing the work we uh originally had oci artifacts that's there that's the single individual objects the uh auras artifacts we think
• 38:00 - 38:30 reference types we've done the incubation under auras we're working with oci to get that submitted as a standard auras and oci obviously both linux foundation projects so we're you know they're available for everybody to use um then the aura cli is how i was using it there think of it as the file system api but if i'm in an application i can do file save and file open within an application right those are libraries for how to interact with the file system we have rs go
• 38:30 - 39:00 which is how you can build your s-bom tool to interact with the registry right so that's we really want to make sure that these things are available for other people to use in their tools your users shouldn't have to think about auras they want to think about your thing your sbom tool your scan results your whatever it is you guys are going to creatively come up with is you can use the rs go libraries to say look i just i don't want to be dealing with storage things i want to leverage what's already there so let me just use this library and i'll do the push discover pull
• 39:00 - 39:30 and then we've got a fork of distribution that supports all of this so um that's it for the talk we have this running in azure aws is coming soon docker's working on their version of it we're we're looking for anybody else that's looking for support and new innovations new ideas our goal here was to not worry about a specific type it was to enable the ecosystem to store all these things and not have to create yet another storage solution so hope that was helpful i'll stick around for
• 39:30 - 40:00 any questions and thank you for coming [Applause]