Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.

Container Defense in Depth

Aug 11th, 2016 8:00am by
Featued image for: Container Defense in Depth
This contributed piece is the first from a number of introductory essays we will run from speakers of To the Cloud and Beyond, a “three day kick-ass conference about Cloud Native Computing” from the Software Circus collective, taking place in Amsterdam, 31 August to 2 September.

The new age of image-based containers exploded onto the scene in early to mid-2013. Since the early days of the Docker container engine, we heard questions of whether they were secure enough. Our very own Dan Walsh was heard many times saying, “Docker containers don’t contain” — so the question is, can we safely use them? Especially in production?

Well, containers are really just fancy files and fancy processes which means that almost all of the current information assurance techniques we have are applicable to containers. In fact, many of the tools we have today can be applied more effectively to containers. If we can reprogram our architect brains a bit, we can apply a lot of what we know today to containers.

Let’s start by thinking about the control points that we have in a containerized environment. There are three main components to a production container environment. We can control information flow at each layer.

The three layers of a container environment.

The three layers of a container environment.


Working from the center, we begin with the container images themselves. Container images are made up of:

  • Operating System Binaries
  • Operating System Libraries
  • Language Runtimes (Java, PHP, Ruby)
  • Middleware (Message Busses, Application Servers)
  • Databases, Datastores
  • Developer Code
Scott McCarty
At Red Hat, Scott McCarty helps to educate IT professionals, customers, and partners on all aspects of Linux containers, from organizational transformation to technical implementation, and works to advance Red Hat's go-to-market strategy around containers and related technologies. He also liaises with engineering teams, both at the product and upstream project level, to help drive innovation by using feedback from Red Hat customers and partners as drivers to enhance and tailor container features and capabilities for the real world of enterprise IT.

Our current operating model controls the flow of this type of content already with physical servers and virtual servers, and it’s actually just as easy to apply to container images. We can utilize and apply techniques such as:

  • Trusted Content (What’s in the container matters. Don’t install from
  • Content Provenance (Track who changed what.)
  • Security Scans
  • Remediation/Patching
  • Bill of Materials
  • CVE Databases
  • Security Response Teams
  • Limit Root Access (Don’t oversell User Namespaces.)
  • Limit User Access (Who controls content.)

Containers add the ability to easily apply techniques such as:

  • Bill of Materials
  • Signing
  • Read-only Containers (Read-only servers were popular in the late 90s.)
  • Atomic diff/Docker diff to see what changed in a container.

Container Hosts

Moving out a ring, to the container host. Many of these techniques, we apply today.

  • Kernel Quality
  • Capabilities
  • Read Only Images
  • Limiting ssh access (root access and users)
  • Well understood/controlled configuration (cloud-init, Ansible)
  • Tenancy

Since containers are just fancy processes with a well-controlled user space, it’s easier to apply techniques like:

  • sVirt
  • Hardening: NO_NEW_PRIVS, Read Only Images, –cap-drop=ALL, –user=user

Container Platform

The container platform layer is where we want to control access for end users and even administrators where possible. This layer exists in the world of physical and virtual servers but is typically an administrator only tool, such as vCenter or HPSA. In the world of containers, it’s much more common to delegate some access to developers, architects, and application owners.

  • Role-Based Authorization
  • Authentication (LDAP, network level access/restriction to the platform)
  • Environment Isolation (development, testing, production)
  • User Demarcation (kubectl exec)
  • Network Separation
  • Key Management


Much of what we know today about information assurance and computer security can be applied in a containerized environment. Some security techniques (read-only servers, tripwire, etc) that we tried before were difficult to use with virtual machines but are made easier with containers. Containers don’t contain, but good technical controls can make containers even more secure than regular processes — information assurance techniques need to be thoughtfully applied in layers.

Come join me at Software Circus and let’s talk about container defense in depth. I am going elaborate on the above concepts with the goal of attendees walking away with the ability to apply these information assurance techniques in their own environments.

Docker and Red Hat are sponsors of The New Stack.

Feature image by Aron Van de Polvia Unsplash.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack, Docker.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.