Zapping around Microservices

/ Berthold Schulte

Recently at a meetup about microservices, RESTful & Co. I thought about the following conversation, just before the next talk started:
‚We are now doing Microservices and the first dozen is already in production.‘ ‚Quite nice, and how do you do security?‘ the other guy asked. A few seconds of silence followed. ‚Actually we do not need security, they are just used internally and everything is behind a firewall‘. The next talk began – about bounded contexts.

However, security is not only a matter of preventing attacks and threats from outside of the own systems. Even internal clients like other services could run mad and harm a service. I.e. security is also a matter of misusage or unexpected usage of a service.
One weak part of a RESTful service is its interface and the possibilities how to use it, respectively how to ensure that is used as it is intended to be used. Of course, validation is one part of the story how to deal with harming usage, but the story starts before validation and does not end with it, as described by the Open Web Application Security Project (OWASP):

Assist the user > Reject input > Sanitize (filtering) > No input validation

Covering all that aspects in one small blog post won’t fit – but it’s worth skimming the OWASP advice how to secure and validate RESTful services.

If you work on the validation part of your service i.e. validating of parameters, URLs, payload, attributes etc., testing the interface is obligatory and must be done as early as possible. Having tests in place, to get an idea how a service works in case of unexpected usage, could be a good idea too. In addition to lots of security advice, the OWASP initiative provides the tool Zed Attack Proxy (ZAP). Besides automated security testing, ZAP can help you to get an idea how the application responses in case of the unexpected usage – even automated. To get an overview about automated test-support of ZAP in terms of the unexpected usage of a service, have a glance at ZAP’s Fuzzer Concept:

Fuzzing is a technique of submitting lots of invalid or unexpected data to a target.

Basic components of the Fuzzer are:

Payload Generators: Payload Generators generate the raw attacks that the fuzzer submits to the target application.
Payload Processors: Payload Processors can be used to change specific payloads before they are submitted.
Fuzz Location Processors: Fuzz Location Processors can be used to change all of the payloads before they are submitted.
Message Processors: Message Processors can access and change the messages being fuzzed, control the fuzzing process and interact with the ZAP UI.

… quite a lot of possibilities to create unexpected messages.

At the end of the day the first step is to be aware of possible misusage and unexpected usage of a service and the issues that could occur. Unfortunately it is not possible to anticipate all unexpected usage issues – but that’s immanent in this case.

Context switch in kubernetes

/ Berthold Schulte

Recently the following shell command passed my desk:

kubectl config use-context

I ask myself, wow use-context, what a powerful command. What’s the intention of this command? Context is a meaningful word and using a special context with one instruction could be awesome.

In general context could be described like:

The surroundings, circumstances, environment, background or settings that determine, specify, or clarify the meaning of an event or other occurrence. – wiktionary

However kubectl is a command line interface of the cluster management platform kubernetes. And kubectl is just a tool to handle a zoo of application containers hosted in a distributed system landscape based on docker and kubernetes.

It turned out that the command use-context just switches between configurations which set a cluster, a user and a namespace. Though the next meanigful word passed by: namespace. By studying kubernetes‘ website I found a few definitions respectively descriptions of namespace – luckily with a similar intention.

Admin guide

A Namespace is a mechanism to partition resources created by users into a logically named group.

Concept guide

A namespace is like a prefix to the name of a resource. Namespaces help different projects, teams, or customers to share a cluster, such as by preventing name collisions between unrelated teams.

User-Guide – Glossary

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.

Thus it is nothing more than keeping things unique and eventually keeping things separated. A more general and abstract description of a namespace is given by Wikipedia:

In computing, a namespace is a set of symbols that are used to organize objects of various kinds, so that these objects may be referred to by name. Prominent examples include:
[…] computer networks and distributed systems assign names to resources, such as computers, printers, websites, (remote) files, etc. Wikipedia

Finally a namespace in kubernetes is more or less treated as I would expect it. But quite frankly by skimming the documentation I got the impression there must exit something with security and restricting access to namespaces too. Especially in the IT keeping sings separated means keeping things secure in terms of getting access to it.
After further research a kubernetes blog post appeared, which elaborates the usage of namespaces and furthermore provides dos and don’ts using namespaces when planning kubernetes clusters. Kubernetes Namespaces: use cases and insights.
They are aware of such security concerns and perhaps plan to address them soon:

[…] Kubernetes does not (currently) provide a mechanism to enforce security across Namespaces. You should only use Namespaces within trusted domains (e.g. internal use) and not use Namespaces when you need to be able to provide guarantees that a user of the Kubernetes cluster or ones its resources be unable to access any of the other Namespaces resources. This enhanced security functionality is being discussed in the Kubernetes Special Interest Group for Authentication and Authorization […].

To get back to the term context, luckily at the end of that post it appeared:

Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. […] The other way to avoid using the wrong namespace is to set a kubectl context.

A quite nice and concise explanation of context in regards to kubernetes – my favorite one.

Finally I’d like to encourage you to read that post and get an insight how to use namespaces and when to switch the context.