Return to Answer

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see cri-o.io. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running rkt. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running in production. An external security audit is a smart investment.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they fine on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that run Docker.

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see cri-o.io. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running rkt. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running in production. An external security audit is a smart investment.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they find on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that use Docker.

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see cri-o.io. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running rkt. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they fine on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that run Docker.

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see cri-o.io. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running rkt. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running in production. An external security audit is a smart investment.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they fine on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that run Docker.

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see cri-o.io. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running rkt. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they fine on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that run Docker.

Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.

Misconfiguration of docker demon itself can also introduce security risks. It's fairly common for complex software to have security tuning tools and to run them as part of ”operational readiness checks” of the live environment before going live as a security audit. Then also run them on some periodic cycle or after any major upgrades of the software that is being audited. The tools you name will be very useful for that purpose.

Software vendors who build container orchestrators are actively working in removing any dependency on needing to run docker demon see cri-o.io. Security, footprint and fork time are areas that vendors are competing on. CoreOS was a big innovator in this space before they were acquired you can look at some of their architecture presentations to get a flavor of what containers at scale workout docker looks like.

From a devops perspective we should empower devs to run security tools all the time to fix issues early. In practice devs might be using Docker for Windows locally but the live env would be a container orchestrator possibly running rkt. In reality devs in large organizations are not going to security scan infrastructure they didn't create and dont have root on. Even at a startup not every dev can be familiar with all of the tooling and software running.

IMHO if your teaching containers from a developer perspective it's worth pointing out such tools. Certainly devs in my experience are woefully unaware that running containers they fine on docker hub as root isn't the smartest way to be secure. I would only expect to see such tools to be covered in depth by courses teaching security analysts how to audit systems that run Docker.