NIST Defines Microservices, Application Containers and System Virtual Machines

Commentary::Architecture
Audience::All

I'm back on about microservices again, as I was in my
last post, Microservices and Linters. Because yesterday NIST released a draft of Definition of Microservices, Application Containers and System Virtual Machines, which you can see at http://csrc.nist.gov/publications/PubsDrafts.html#800-180.

I have problems with it. The public comments period runs through 2016-03-18, and a comment template is available at the link above. If you don't read many NIST drafts, note that line numbers are part of the document. While that is useful if you catch a typo, or take exception to one statement, it is less useful if you take exception to the entire thing, to the extent of labeling it FUBAR.

That is, of course, just one opinion. I could make a claim about not wanting to bias any opinions, but then I've just done that, to at least some extent. This is mostly about not even knowing where to start, regarding this specific document.

I still regard microservices as something that is not nearly as widely deployed as one might think, given the trade press hype coverage. But it might be nice if, for once, security considerations might be taken into account early in the game. Yes, that is a forlorn hope, but even long odds will come home, given enough time.

Bur, srsly.  "Microservices are built around capabilities as opposed to services..."? Wut? I am not at all convinced that we have a robust system, Linux or otherwise, based on the capabilities security model. Because

• the capabilities security model is still a current research topic
• implementations will contain flaws or a long time to come
• all microservices architectures I have seen have been composed around the services (function) model

In this case, NIST seems to muddy the water through poor definitions. Particularly as it seems unlikely that wide awareness of capabilities-based security models, even as a research topic, exists at all within the wider software developer community. I've certainly seen little evidence for it, for whatever that might be worth.

Perhaps their usage of 'capabilities' was all about a possibly rapid evolution of APIs in containerized software, and not the capabilities security model. But rapid replacement of containerized software is about far more than API changes. Rather importantly, they are also about bug fixes. A percentage of which have always been exploitable, and as these are inherently remotely-accessible, would tend to have severity numbers reflecting that broad attack surface.

A lack of clarity over what, exactly, 'capabilities' might mean, in a NIST publication with 'Definition' in the title is, in and of itself, a problem.

Of course this is just anecdotal, from some random security worker. Not even remotely real evidence. So please ask around in your own organization, form your own conclusions, and comment on 800-180, if at all, as you see fit.

UUID: 92ce460e-58a6-4fd1-b3ed-d44f2d9c0183

Microservices and Linters

Commentary::Coding

Audience::Entry

Microservices are all the rage at the moment, for good reason. I am of course interested in the security aspects, and I am also on record as loving me some Python. Why, in detail, is probably something I should write up in a future post. For now, I'm just going to mention an intersection between the two.

In Chapter 9 (Security) of Building Microservices (Sam Newman, O'Reilly, 2015) we have exactly one mention of static analysis, under Baking Security In. Please don't misunderstand me – I found Building Microservices a worthwhile read. It is, however, a rather broad overview, and does have an unfortunate tendency to follow fashion. That last is probably not avoidable: the title has to sell, after all. And there is no possible way that all languages, strategies, etc., might be mentioned. So, no points off. Overall, author Sam Newman has done a nice job with this title.

That said, I still have a problem with static testing getting only one mention. Much has been written about developers needing to raise their game. It really is ridiculous that most injection attacks (SQL, LDAP, etc), for example, can exist in 2016. A lot of this is justified, but there are also some bits about QA, where that luxury still exists, that do not seem to get a lot of mention. Test-driven development can only take you so far, and an external QA group is a hugely useful defense against groupthink, deadline pressure, and other sources of problems in the delivery of reliable code.

Real developers could probably provide me with a lengthy list, and are invited to do so. You could further educate me with an ordered list – one can never have too much data.

Circling Back to Python

Back in June Andrew Collette (creator of much Python HDF5 code) wrote an excellent piece:

My Experience Using Static Analysis With Python. He was on Travis CI, and recommended both pyflakes (at minimum) and PyLint.

As it happens, we ended up using PyLint, which found about 100 legitimate issues with the code base, ranging from missing docstrings to calls to functions with the wrong number of arguments.

The takeaway is to use at least some sort of linter. Fine. That's doable, in either a full-on Continous Integration environment, or just using git hooks in a personal repo. Low marginal cost, better code. What's not to like?

Distributed Computing Is Inherently Complicated

Modern computing environments may consist of a single machine, comprised of multiple threads on multiple cores, many nodes in a cluster, or extremely parallel computing via GPU. In some cases (RDMA comes to mind), basic security mechanisms provided by Unix-like kernels are already being bypassed.

The need for reliable user-land code is never going to decrease. If even a minor improvement can be had by using something as widely known as a linter, yet that is not a universally accepted practice, then we are collectively Doing It Wrong.

UUID: d4b72b13-5dd1-46d1-913a-9dc470e0b6d7