Singularity: Simple. Fast. Secure.
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Arango, Eduardo
One of the biggest problems in scientific HPC is ensuring that results are reproducible. That is, the code a scientist runs locally must be able to run identically on any computational resource. Until recently, the job of ensuring that fell to system administrators who needed to manage a complex web of tools and dependencies on those resources. However, with the introduction of HPC containers via Singularity, the ability to mobilize the compute environment has never been easier. Singularity allows anybody to run their own containers on HPC, ushering in a new era of computational mobility, validity, and reproducibility. Singularity is the most widely used container solution in high-performance computing (HPC). Enterprise users interested in AI, Deep Learning, compute drive analytics, and IOT are increasingly demanding HPC-like resources. Singularity has many features that make it the preferred container solution for this new type of “Enterprise Performance Computing” (EPC) workload. Instead of a layered filesystem, a Singularity container is stored in a single file. This simplifies the container management lifecycle and facilitates features such as image signing and encryption to produce trusted containers. At runtime, Singularity blurs the lines between the container and the host system allowing users to read and write persistent data and leverage hardware like GPUs and Infiniband with ease. The Singularity security model is also unique among container solutions. Users build containers on resources they control or using a service like the Sylabs Remote Build Service. Then they move their containers to a production environment where they may or may not have administrative access and the Linux kernel enforces privileges as it does with any other application. These features make Singularity a simple, secure container solution perfect for HPC and EPC workloads. One of the biggest problems in scientific HPC is ensuring that results are reproducible. That is, the code a scientist runs locally must be able to run identically on any computational resource. Until recently, the job of ensuring that fell to system administrators who needed to manage a complex web of tools and dependencies on those resources. However, with the introduction of HPC containers via Singularity, the ability to mobilize the compute environment has never been easier. Singularity allows anybody to run their own containers on HPC, ushering in a new era of computational mobility, validity, and reproducibility. Singularity is the most widely used container solution in high-performance computing (HPC). Enterprise users interested in AI, Deep Learning, compute drive analytics, and IOT are increasingly demanding HPC-like resources. Singularity has many features that make it the preferred container solution for this new type of “Enterprise Performance Computing” (EPC) workload. Instead of a layered filesystem, a Singularity container is stored in a single file. This simplifies the container management lifecycle and facilitates features such as image signing and encryption to produce trusted containers. At runtime, Singularity blurs the lines between the container and the host system allowing users to read and write persistent data and leverage hardware like GPUs and Infiniband with ease. The Singularity security model is also unique among container solutions. Users build containers on resources they control or using a service like Singularity Hub. Then they move their containers to a production environment where they may or may not have administrative access and the Linux kernel enforces privileges as it does with any other application. These features make Singularity a simple, secure container solution perfect for HPC and EPC workloads. Singularity blocks privilege escalation within the container so if a user wants to be root inside the container, it must be root outside the container. This usage paradigm mitigates many of the security concerns that exists with containers on multi-tenant shared resources. You can directly call programs inside the container from outside the container fully incorporating pipes, standard IO, file system access, X11, and MPI. Keywords HPC, Linux Containers, Singularity, Docker, LXC, portability References Kurtzer, G. M. (2016). Singularity 2.1.2 - Linux application and environment containers for science. Zenodo. LinuxContainers.org Infrastructure for container projects. Project sponsored by Canonical Ltd.
 Good morning. My name is Eduardo. Again, I work for PsyLabs. And I'm here to give a quick update on what new on-segregation is last year. So we had Michael Bauer last year here at Fosem at the HPC track. So I'm here to talk more about what changed since that day. So a quick brief history for the people that doesn't know about similarity. It was invented by Greg Corsair in the National Laboratories back in 2015. In October, around something about October, people asking really how can they take their own environment from their desktops, their workstations to the infrastructure cluster. The first really released, like the 1.0 was some point around April of 2016. And thanks to user feedback and open source contribution, and that's kind of when I started to contribute to singularity also. It got into 2.0 in June of 2016. But after that, things are going pretty, pretty fast. And Greg founded PsyLabs last year in January. And we are now around 28 engineers working day by day making singularity better. And trying to get user feedback on how can singularity help them do their work faster. And this talk is going to be focused around a release 3.0 that was released in October last year. And comes with a lot of new features, more stability for users. And a new language update, so open source contributions can jump in easily than it was before 3.0. So a quick thank you to all the open source supporters for singularity. Last year we won three HPC wire users and Editor Choice Award at Supercomputing. And we know that it's thanks to all you guys. So really thanks for the support. And this is all the people and institutions right now using singularity on production systems and giving back contributions to the open source singularity. So once again, thanks to you for these awards. So this is a gear update on singularity. And the next slide is going to hit half, or more of half of the people here. And it's go. So singularity last year was a monster that was like bash, Python, C, and they kind of talk each other. It was really hard for a new open source contributor to jump in and start contributing to singularity from the user's point of view. From the stability point of view, Python was giving us a lot of dependency issues when trying to move singularity in between systems. And also the third reason was people were asking to integrate singularity with all the cloud tools out there that HPC people are really trying to leverage. Things like Q and N, things like cloud native tools. So in order to interact easier and more natively with those tools, we start to consider moving to go to the point on which, some point around February last year, we started a whole rewire of the code. And now singularity is Python free. And it's a C-go project. So it's mostly go code. We are only using C code for the security bits, like doing the system calls and interacting with the kernel. But all the rest is made in go. So I always try to get new people into singularity. And I think go is a language for new people. There is really easy to just jump in, read some lines of code, understand the language, of course, and start helping with open source contributions. What do we like? A part of the integration with the cloud native tools out there is the concurrency model go as a developer. It's really easy to track threads. And it's really easy to know what's happening with your code at runtime. And the last line I'm going to show you in our next slide, what is CNI as the container networking interface. So with the 3.0 version of singularity, you can start doing poor mapping and network virtualization. We've faced some challenges. So if you are following the singularity open source, it was quite of a year moving a code from Bash and Python and taking that to C. So the first main point was choosing C-go interface. I know in the go world, C-go is still opinionated, but it's really needed when you're trying to do security bits and system calls. And you need to control them from a C point of view. Because all the C-coders here know that C gives you the entire control of the system. We are following the go standards on packaging. So if you are a regular go developer that doesn't know anything about container, file systems or the underground of how singularity works, when you jump into our code base, you are going to feel familiar in a go project. We are using rendering. So this third line is when we say we are Python free, because right now if you do a clean git clone, you can start making style without bothering or having all the Python dependencies. And if you have Python 2 or Python 3 and the failure that we were having with some users, already in a newer person of Python trying to compile singularity, some point around two years from now. And so this is really nice now that you can just do a clean git clone and start building singularity because everything, the rendering folder is there. So all the dependencies are already in the repo. Packaging, building a C-go project that complex as singularity took us to overthink how auto tools work because auto tools is too complicated for things too much complicated, but not as complicated as a go project. Go is kind of easy to build. So one of the engineers designed make it. So if a homemade tool for building RPM and that packages, the debt is still under work, but you can right now jump into the singularity project and start building your RPM and distributing the RPM package. Differences that we are already seeing against Python is we have a lot of APIs and ecosystems out there that we can start leveraging out of the box. So one of the main releases this year is that singularity right now can interact with Kubernetes. So if you go to the side lab, a git group, you can see a CRI repo and that's your repo is really how singularity can integrate with Kubernetes. So thanks to go because it gave us just the native APIs for Kubernetes and we can just start talking to Kubernetes. Go test. So I'm part of the QA team of singularity and this is really nice. How just, and we were talking about tests and doing just batch tests, we are moving our simple batch test from the 2.x version into a more complex and a more robust way of testing singularity. So if you see singularity right now on the test portion, we are doing unit testing and integration testing, things that were not happening in the 2.x version. 2.x version was only doing integration testing but not testing at the level of unit testing. So by leveraging Go, singularity is more robust project now because it has a bigger and robust test suite. It's very easy and productive as a developer to write in Go. So rather than trying to understand how the batch script raises some environment variables, Python rate it and code C, which was the 2.x version, right now you can just understand everything by reading the Go code. So it's a single file of Go versus trying to open a batch, Python and C file and understand what's happening between those three files. Go is very opinionated. I know, I told you that that slide was going to chug some of the people here but we are already seeing people trying the 3.0 version of singularity and production and it's very stable and I encourage you to try it. One of the big changes a part of moving from Python C to Go is the image format. So right now singularity is using its own image format called SIF, singularity is mass format versus 2.x, people familiar with 2.x, it was you could use exetreat images or squashFS images. So for 3.0 we are using a homemade image format and that gives us a lot of new features. So you can store metadata in the headers. So you can see it as a tar file but optimized for container usage. So you can store your squashFS image in the big object in the middle. So it's a read-only image. But rather than just storing the squashFS image, you can also store metadata in the headers that you can see here. And upcoming maybe in 3.2 or 3.3 version of singularity, we are going to have a writeable overlay that is going to be apart from the signature block. So on the next slide I'm going to show that also in 3.0 you can sign with a PGP protocol your containers. So you can sign your containers and send those keys and the container to a friend, to a peer reviewer and they can check that the image is immutable and hasn't changed during the sending or maybe someone switched it for another image on the way. So we are very proud of our new image format. And as a developer also if you are maybe like an ECBU or tools like that, you can start leveraging the metadata in the headers to tell the scheduler to tell your runtime how to use that root file system that is in the middle in the squashFS format. So what's new in 3.0 on the cloud side? So right now users can have a container library. So this is apart from singularity hub, so people familiar with singularity hub, which is supported and maintained by Stanford and I guess you are now Vanessa. SILabs right now has a container library which is optimized for SIF. So you can only pull and push SIF images because it's just for the 3.0 and above. You cannot push images from 2.x versions. We have our remote build service. So a lot of users will say we're telling us, yeah, singularity is good. I want to jump into singularity by my university. My institution doesn't allow me to have pseudo even in my workstation in my laptop. So how can I start building my own images and testing my own images before giving them to the system admin? So if you are running into this issue, you can go into the SILabs white page and give us your definition file and we are going to give you back your SIF file without a pseudo need. And last but not least, the key store service. So you can now sign your containers as I was telling you, but when you want to move those keys between hosts, you can use the SILabs key store service for free. And that way you can sign your container, let's say your workstation, tell your system admin about your keys and he's going to be able to verify that that container comes from XYG user. So I'm going to show it here how it looks. So this is the SILabs web page and you can see up there, sorry I'm facing you, this is the library, the remote builder and the key store. So this is how the library looks. I'm signing a SILabs ad. This is my login. And we have some statistics here from different users and how are they pulling and pushing their containers. And this is the remote builder. So I was telling you, you can drag and drop your definition file into this black and to this white box, you can start writing your definition file here and you build it and we are going to build it for you here with a live output from the cloud infrastructure where this is happening. And after all this, we're going to give users direct download so you can just click and download your singularity image and start using it. Or if you don't want to click that link, we are going to give you a library link so your image is going to be stored here. So you cannot download it because you just want to build the image and then pull it from the cluster or pull it from another host. So this is how an image looks when stored in the container library. And this is the key store. As you can see here, I have two keys stored and I can use these keys to sign containers on my host and then share those containers with partners, peer reviewers, and they can verify that that container comes from me with a PGP based key. Okay, I was showing you this. This is how interacting with the library looks. So it's really easy. Singularity 2.x had the pull CLI but not the push. So 3.0 introduced push command so you can push your container into the cloud. You can create tokens. This is via web UNI. And you can also from the CLI search containers public available in the library. So we have private images and public images as GitHub as other hubs out there. So this search command is only going to work for public available images. So let's say you're interested in pulling a quick OVUN to a quick Fedora image and you don't want to type library.data slash slash something something Fedora. You just go and singularity search for me a Fedora image. Singularity search for me a OVUN2 image and we are going to retrieve to you all the public available images that are OVUN2 or Fedora based image. This is how users can interact with the remote builder also from the CLI. So rather than changing all the CLI we just added a small flag is dash dash remote. So if you know that you don't have pseudo privileges in your post you just run singularity build dash dash remote and the rest is the same. And you can just point to your definition file and we are going to build that for you in the cloud from the CLI. So there's no need on going into the web page to use the remote builder. You can use the remote builder from the CLI. For doing this you do need one GUI step which is the create token. So you need to go to the web page and create your token. That's hard to do from the CLI. The key store. This is how users can interact with the key store from the CLI. So it's really easy. If you don't have a keeper already in your host, singularity is going to talk with the PGP protocol already in your hosting create some keys for you. You can list keys. You can have several keys not just one key but several keys stored in the singularity. A key folder. You can push them and you can also search keys as you can search for images. So I have three minutes. Moving away from cloud functionalities. Users can now do network virtualization. So you can now do poor mapping set hostname DNS create bridges go wild with network virtualization with singularity containers. So we are seeing users back in super computer. I see some really nice use cases on deploying web services through singularity and doing poor mapping to do remote visualization over GPO clusters. So this is a pretty powerful tool for users. Security. This is only for system admin singularity is always trying to give more power to the system admin to control the users. System admins come out at capabilities or remote capabilities depending on the user allowed or not allowed set UID for users and keep privilege. So this that dash privilege can make users run singularity in size. Singularity crazy things like that. And a security bid that encourage you to read the documentation on how system admin can enhance singularity documentation from the CLI. Also we have to support this feature requires running by pseudo. But you can now block or limit the CPU the memory the IO everything that you can block using C group. You can now block your singularity processes out of the box. And one minute sign and verify. So I was telling you what showing you the key store that you can now sign and verify. So this is how the CLI looks when running a sign and verification on your singularity images. Okay. Was going to show them. Okay. And the last thing that I'm going to show which is something I really like. Is this file. So this file is mostly for system admins. So you can now create widely or blacklist for keys. So you can say in this cluster all the singularity images must run sign it and you can create List keys are going to run and let's say you fire some user you fire some student from the infrastructure. You can add them to the blacklist and just say OK this student key will not run even if he's trying with pseudo Privileges singularity is going to block that image from running via this configuration files. This configuration files really powerful for system admin on blocking and leveraging the sign and verify Feature of the 3.0 version. And with one minute questions. And we are hiring we are really interested in getting more developers people with HPC knowledge with system related Knowledge. So if you're interested in being a container person talk to me after this. Any question. Oh no. Yeah. I switched them. Yeah because we already had a singularity one on one here at Fosn. So the committee really asked me to be more an update the jazz one on one. So that's that's why. Not yet. So a question here is that if you can install the cloud services of singularity on premise like in your own cluster that feature is coming some point around let's say after August September. So we are working on that. Keep keep an eye on the singularity report that feature is coming. We're working on that. So you can install the library the builder the key store in your host not depending on our infrastructure.
 Good morning.  My name is Eduardo.  Again, I work for PsyLabs.  And I'm here to give a quick update on what new on-segregation is last year.  So we had Michael Bauer last year here at Fosem at the HPC track.  So I'm here to talk more about what changed since that day.  So a quick brief history for the people that doesn't know about similarity.  It was invented by Greg Corsair in the National Laboratories back in 2015.  In October, around something about October,  people asking really how can they take their own environment from their desktops,  their workstations to the infrastructure cluster.  The first really released, like the 1.0 was some point around April of 2016.  And thanks to user feedback and open source contribution,  and that's kind of when I started to contribute to singularity also.  It got into 2.0 in June of 2016.  But after that, things are going pretty, pretty fast.  And Greg founded PsyLabs last year in January.  And we are now around 28 engineers working day by day making singularity better.  And trying to get user feedback on how can singularity help them do their work faster.  And this talk is going to be focused around a release 3.0 that was released in October last year.  And comes with a lot of new features, more stability for users.  And a new language update, so open source contributions can jump in easily than it was before 3.0.  So a quick thank you to all the open source supporters for singularity.  Last year we won three HPC wire users and Editor Choice Award at Supercomputing.  And we know that it's thanks to all you guys.  So really thanks for the support.  And this is all the people and institutions right now using singularity on production systems  and giving back contributions to the open source singularity.  So once again, thanks to you for these awards.  So this is a gear update on singularity.  And the next slide is going to hit half, or more of half of the people here.  And it's go.  So singularity last year was a monster that was like bash, Python, C, and they kind of talk each other.  It was really hard for a new open source contributor to jump in and start contributing to singularity  from the user's point of view.  From the stability point of view, Python was giving us a lot of dependency issues  when trying to move singularity in between systems.  And also the third reason was people were asking to integrate singularity with all the cloud tools out there  that HPC people are really trying to leverage.  Things like Q and N, things like cloud native tools.  So in order to interact easier and more natively with those tools,  we start to consider moving to go to the point on which,  some point around February last year, we started a whole rewire of the code.  And now singularity is Python free.  And it's a C-go project.  So it's mostly go code.  We are only using C code for the security bits,  like doing the system calls and interacting with the kernel.  But all the rest is made in go.  So I always try to get new people into singularity.  And I think go is a language for new people.  There is really easy to just jump in, read some lines of code,  understand the language, of course, and start helping with open source contributions.  What do we like?  A part of the integration with the cloud native tools out there  is the concurrency model go as a developer.  It's really easy to track threads.  And it's really easy to know what's happening with your code at runtime.  And the last line I'm going to show you in our next slide,  what is CNI as the container networking interface.  So with the 3.0 version of singularity,  you can start doing poor mapping and network virtualization.  We've faced some challenges.  So if you are following the singularity open source,  it was quite of a year moving a code from Bash and Python and taking that to C.  So the first main point was choosing C-go interface.  I know in the go world, C-go is still opinionated,  but it's really needed when you're trying to do security bits and system calls.  And you need to control them from a C point of view.  Because all the C-coders here know that C gives you the entire control of the system.  We are following the go standards on packaging.  So if you are a regular go developer that doesn't know anything about container,  file systems or the underground of how singularity works,  when you jump into our code base,  you are going to feel familiar in a go project.  We are using rendering.  So this third line is when we say we are Python free,  because right now if you do a clean git clone,  you can start making style without bothering or having all the Python dependencies.  And if you have Python 2 or Python 3 and the failure that we were having with some users,  already in a newer person of Python trying to compile singularity,  some point around two years from now.  And so this is really nice now that you can just do a clean git clone  and start building singularity because everything, the rendering folder is there.  So all the dependencies are already in the repo.  Packaging, building a C-go project that complex as singularity took us to overthink  how auto tools work because auto tools is too complicated for things too much complicated,  but not as complicated as a go project.  Go is kind of easy to build.  So one of the engineers designed make it.  So if a homemade tool for building RPM and that packages,  the debt is still under work,  but you can right now jump into the singularity project  and start building your RPM and distributing the RPM package.  Differences that we are already seeing against Python  is we have a lot of APIs and ecosystems out there that we can start leveraging out of the box.  So one of the main releases this year is that singularity right now can interact with Kubernetes.  So if you go to the side lab, a git group, you can see a CRI repo  and that's your repo is really how singularity can integrate with Kubernetes.  So thanks to go because it gave us just the native APIs for Kubernetes  and we can just start talking to Kubernetes.  Go test. So I'm part of the QA team of singularity and this is really nice.  How just, and we were talking about tests and doing just batch tests,  we are moving our simple batch test from the 2.x version  into a more complex and a more robust way of testing singularity.  So if you see singularity right now on the test portion,  we are doing unit testing and integration testing,  things that were not happening in the 2.x version.  2.x version was only doing integration testing but not testing at the level of unit testing.  So by leveraging Go, singularity is more robust project now  because it has a bigger and robust test suite.  It's very easy and productive as a developer to write in Go.  So rather than trying to understand how the batch script  raises some environment variables, Python rate it and code C,  which was the 2.x version, right now you can just understand everything  by reading the Go code.  So it's a single file of Go versus trying to open a batch,  Python and C file and understand what's happening between those three files.  Go is very opinionated.  I know, I told you that that slide was going to chug some of the people here  but we are already seeing people trying the 3.0 version of singularity and production  and it's very stable and I encourage you to try it.  One of the big changes a part of moving from Python C to Go is the image format.  So right now singularity is using its own image format called SIF,  singularity is mass format versus 2.x, people familiar with 2.x,  it was you could use exetreat images or squashFS images.  So for 3.0 we are using a homemade image format and that gives us a lot of new features.  So you can store metadata in the headers.  So you can see it as a tar file but optimized for container usage.  So you can store your squashFS image in the big object in the middle.  So it's a read-only image.  But rather than just storing the squashFS image,  you can also store metadata in the headers that you can see here.  And upcoming maybe in 3.2 or 3.3 version of singularity,  we are going to have a writeable overlay that is going to be apart from the signature block.  So on the next slide I'm going to show that also in 3.0 you can sign with a PGP  protocol your containers.  So you can sign your containers and send those keys and the container to a friend,  to a peer reviewer and they can check that the image is immutable and hasn't changed during the sending  or maybe someone switched it for another image on the way.  So we are very proud of our new image format.  And as a developer also if you are maybe like an ECBU or tools like that,  you can start leveraging the metadata in the headers to tell the scheduler to tell your runtime  how to use that root file system that is in the middle in the squashFS format.  So what's new in 3.0 on the cloud side?  So right now users can have a container library.  So this is apart from singularity hub, so people familiar with singularity hub,  which is supported and maintained by Stanford and I guess you are now Vanessa.  SILabs right now has a container library which is optimized for SIF.  So you can only pull and push SIF images because it's just for the 3.0 and above.  You cannot push images from 2.x versions.  We have our remote build service.  So a lot of users will say we're telling us, yeah, singularity is good.  I want to jump into singularity by my university.  My institution doesn't allow me to have pseudo even in my workstation in my laptop.  So how can I start building my own images and testing my own images before giving them to the system admin?  So if you are running into this issue, you can go into the SILabs white page  and give us your definition file and we are going to give you back your SIF file without a pseudo need.  And last but not least, the key store service.  So you can now sign your containers as I was telling you, but when you want to move those keys between hosts,  you can use the SILabs key store service for free.  And that way you can sign your container, let's say your workstation, tell your system admin about your keys  and he's going to be able to verify that that container comes from XYG user.  So I'm going to show it here how it looks.  So this is the SILabs web page and you can see up there, sorry I'm facing you,  this is the library, the remote builder and the key store.  So this is how the library looks. I'm signing a SILabs ad. This is my login.  And we have some statistics here from different users and how are they pulling and pushing their containers.  And this is the remote builder. So I was telling you, you can drag and drop your definition file into this black and to this white box,  you can start writing your definition file here and you build it and we are going to build it for you here with a live output from the cloud infrastructure where this is happening.  And after all this, we're going to give users direct download so you can just click and download your singularity image and start using it.  Or if you don't want to click that link, we are going to give you a library link so your image is going to be stored here.  So you cannot download it because you just want to build the image and then pull it from the cluster or pull it from another host.  So this is how an image looks when stored in the container library.  And this is the key store. As you can see here, I have two keys stored and I can use these keys to sign containers on my host and then share those containers with partners, peer reviewers,  and they can verify that that container comes from me with a PGP based key.  Okay, I was showing you this. This is how interacting with the library looks. So it's really easy.  Singularity 2.x had the pull CLI but not the push. So 3.0 introduced push command so you can push your container into the cloud.  You can create tokens. This is via web UNI. And you can also from the CLI search containers public available in the library.  So we have private images and public images as GitHub as other hubs out there.  So this search command is only going to work for public available images. So let's say you're interested in pulling a quick OVUN to a quick Fedora image  and you don't want to type library.data slash slash something something Fedora.  You just go and singularity search for me a Fedora image. Singularity search for me a OVUN2 image and we are going to retrieve to you all the public available images  that are OVUN2 or Fedora based image. This is how users can interact with the remote builder also from the CLI.  So rather than changing all the CLI we just added a small flag is dash dash remote.  So if you know that you don't have pseudo privileges in your post you just run singularity build dash dash remote  and the rest is the same. And you can just point to your definition file and we are going to build that for you in the cloud from the CLI.  So there's no need on going into the web page to use the remote builder. You can use the remote builder from the CLI.  For doing this you do need one GUI step which is the create token. So you need to go to the web page and create your token.  That's hard to do from the CLI. The key store. This is how users can interact with the key store from the CLI.  So it's really easy. If you don't have a keeper already in your host, singularity is going to talk with the PGP protocol already in your  hosting create some keys for you. You can list keys. You can have several keys not just one key but several keys stored in the singularity.  A key folder. You can push them and you can also search keys as you can search for images.  So I have three minutes. Moving away from cloud functionalities. Users can now do network virtualization.  So you can now do poor mapping set hostname DNS create bridges go wild with network virtualization with singularity containers.  So we are seeing users back in super computer. I see some really nice use cases on deploying web services through singularity and doing poor mapping to do  remote visualization over GPO clusters. So this is a pretty powerful tool for users. Security. This is only for system admin singularity is always trying to give more power to the system  admin to control the users. System admins come out at capabilities or remote capabilities depending on the user allowed or not allowed set UID for users and  keep privilege. So this that dash privilege can make users run singularity in size. Singularity crazy things like that.  And a security bid that encourage you to read the documentation on how system admin can enhance singularity documentation from the CLI.  Also we have to support this feature requires running by pseudo. But you can now block or limit the CPU the memory the IO everything that you can block using  C group. You can now block your singularity processes out of the box. And one minute sign and verify. So I was telling you what showing you the key store that you can now sign and verify.  So this is how the CLI looks when running a sign and verification on your singularity images. Okay.  Was going to show them. Okay. And the last thing that I'm going to show which is something I really like.  Is this file. So this file is mostly for system admins. So you can now create widely or blacklist for keys. So you can say in this cluster all the singularity images must run sign it and you can create  List keys are going to run and let's say you fire some user you fire some student from the infrastructure. You can add them to the blacklist and just say OK this student key will not run even if he's trying with pseudo  Privileges singularity is going to block that image from running via this configuration files. This configuration files really powerful for system admin on blocking and leveraging the sign and verify  Feature of the 3.0 version. And with one minute questions. And we are hiring we are really interested in getting more developers people with HPC knowledge with system related  Knowledge. So if you're interested in being a container person talk to me after this.  Any question.  Oh no. Yeah. I switched them. Yeah because we already had a singularity one on one here at Fosn. So the committee really asked me to be more an update the jazz one on one.  So that's that's why.  Not yet. So a question here is that if you can install the cloud services of singularity on premise like in your own cluster that feature is coming some point around let's say after August September.  So we are working on that. Keep keep an eye on the singularity report that feature is coming. We're working on that. So you can install the library the builder the key store in your host not depending on our infrastructure.
Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_0_47.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_48_155.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_156_683.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_684_3071.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_3072_4007.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_4008_4235.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_4236_7715.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_7716_11507.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_11508_14987.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_14988_20939.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_20940_22067.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_22068_22115.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_22116_22619.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_22620_22715.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_22716_23075.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_23076_23135.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_23136_23687.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_23688_23735.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_23736_30467.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_30468_30563.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_30564_30647.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_30648_30695.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_30696_30755.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_30756_32627.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_32628_32843.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_32844_34355.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_34356_34451.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_34452_34547.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_34548_34883.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_34884_35279.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_35280_35387.png Reproducible_science_with_containers_on_HPC_through_Singularity_Singularity_containers_yqgL9cwEx3M_35388_35502.png