3 ms·

In a few words. With CoreOS Tectonic we are reducing the toil teams endure to update both application infrastructure and applications. We believe that security

In a few words. With CoreOS Tectonic we are reducing the toil teams endure to update both application infrastructure and applications. We believe that security begins with a simple regular processes for getting updates to software out the door and that our tools and products remove toil from these processes. Two sides of the problem: Infra: CoreOS Tectonic[1] provides one-click updates of the entire app infra stack from the VM/bare-metal Linux instances[2] through the Tectonic control plane including Kubernetes, identity services, monitoring tooling, etc[3]. We call this automated operations. App: By leveraging Kubernetes APIs application teams can roll. Further container scanning tools enable app teams to scan in-use containers for CVEs. [1] https://coreos.com/tectonic https://coreos.com/tectonic [2] https://coreos.com/blog/introducing-container-linux-update-operator https://coreos.com/blog/introducing-container-linux-update-o... [3] https://coreos.com/blog/announcing-tectonic-1.7.1 https://coreos.com/blog/announcing-tectonic-1.7.1

3D5AE1F1 9y ago
A few years ago I worked at a big company that desperately needed something like this. Without it we more than did our part to make the internet less secure. Without containers, software releases and infrastructure upgrades were highly interdependent. The result was that the software never released and the infrastructure never got upgraded. Being able to upgrade individual services, independently of the infrastructure, is a bigger enabler than you would think in a large company. When you enable this, teams are suddenly able to release more often. Features ship faster and the lifetime of application vulnerabilities shortens. Meanwhile, if Tectonic works as advertised, your infrastructure can auto-update but continue to provide a stable API to the services it supports. Again, the lifetime of vulnerabilities shortens, potentially by a lot.
nwmcsween 9y ago
This is imo a backwards way of doing things properly. Binaries should be sandboxed via a .ctor using seccomp and unshare, preferably in their own section so updating or removal is trivial. The remaning issue is "how can you have multiple tools as an all-in-one container"

3D5AE1F1 9y ago

A few years ago I worked at a big company that desperately needed something like this. Without it we more than did our part to make the internet less secure. Without containers, software releases and infrastructure upgrades were highly interdependent. The result was that the software never released and the infrastructure never got upgraded. Being able to upgrade individual services, independently of the infrastructure, is a bigger enabler than you would think in a large company. When you enable this, teams are suddenly able to release more often. Features ship faster and the lifetime of application vulnerabilities shortens. Meanwhile, if Tectonic works as advertised, your infrastructure can auto-update but continue to provide a stable API to the services it supports. Again, the lifetime of vulnerabilities shortens, potentially by a lot.

nwmcsween 9y ago

This is imo a backwards way of doing things properly. Binaries should be sandboxed via a .ctor using seccomp and unshare, preferably in their own section so updating or removal is trivial. The remaning issue is "how can you have multiple tools as an all-in-one container"