Credential service API issues

First of all, we believe that the |HTTP| |API| that the clients have to use to obtain the call authenticators is both too "heavy" (especially in the case when the calls are made quite often), and opens a new set of potential security issues, in addition to exposing yet another running process to the network.

Secondly, the usage of the |HTTP| protocol is almost unnecessary, the reason being solely because almost any programming language (including shell scripting) provides a technique to execute such |HTTP| calls. However the burden of correctly implementing the handling of status codes, content negotiation, content encoding, and other technicalities is pushed to the developer of the credential service library (at least one for each programming language).

A simple portable solution

Therefore looking at how a similar project solves this issue, namely factotum from the |Plan9| ecosystem |zoti|, we propose to use a synthetic file-system mounted on each host, one that the clients shall use to delegate the credential operations. (In essence we are only replacing the "transport layer" if we might say so.)

At first sight it might seem a more complex solution than the |HTTP|-based one, however absolutely all programming languages offer access to the file-system, usually through a well established API|'s, like the |POSIX| open / read / write / close family of operations.

Example usage snippets

For example one could envisage the following usage of the credential manager directly from the shell, which mirrors the curl calls presented in the previous section.

$$$ ls /mos/services/credential-manager/modules

>>> aws
rackspace
open-nebula

$$$ ls /mos/services/credential-manager/modules/aws/operations

>>> query-auntenticate-v4

$$$ declare _token="$( uuidgen -r )"

$$$ mkdir "/mos/services/credential-manager/modules/aws/operations/execution/${_token}"

$$$ cat \
     >"/mos/services/credential-manager/modules/aws/operations/execution/${_token}/inputs" \
<<'EOS'
// the same input JSON like in the case of `curl` example
EOS

$$$ echo "execute" \
    >"/mos/services/credential-manager/modules/aws/operations/execution/${_token}/control"

$$$ cat \
    <"/mos/services/credential-manager/modules/aws/operations/execution/${_token}/outputs"

>>> // the same output JSON like in the case of `curl` example

$$$ rmdir "/mos/services/credential-manager/modules/aws/operations/execution/${_token}"

Advantages

Although looking at the previous examples, one could conclude that the process is more involved and thus the overhead is greater (there are 5 operations instead of 1), however the actual number of system calls is comparable to the |HTTP|-based |API| (if not lesser in practice). For example, per credential operation execution, in the case of the |HTTP| |API| we have one socket creation, binding and connection, at least one read and write, one socket shutdown and one close system calls, thus 7 in total. In the case of the file-system based |API| we have one directory creation, two open and close, one read and write, and one directory deletion, thus 8 in total. However we are removing the network overhead, and if needed one can reduce the number of system calls to only four in total (one open, write, read and then close).

But the efficiency is not the only reason, in fact it is just a by-product of the technology. Instead the main advantage is that of a much more constrained and well defined access control, because now the authentication and authorization is done by the operating system kernel (which implements the system calls), meanwhile the credential manager only having to implement the operations. (Not to mention that the service is not exposed to the network.)

Therefore the only way in which an attacker can gain access to the credentials is if the operating system itself is compromised.

Disadvantages

There are however drawbacks, especially since now we require one credential manager to run on each host. However this is not a major one, because |mOS| (the |OpenSUSE|-based |Linux| distribution that |SPECS| leverages) eases the execution of such specialized services.

Another potential issue is how the credential manager obtains the credential data, which gets us to the credential store (presented in the next section), that is a remote service which provides access to such credential data, which the manager caches for performance reasons. However even this interaction follows the same pattern of file-system mediated communication (as the credential store will have on each host a proxy).

Therefore in this new scheme, as opposed to the current credential service prototype, we only need to secure the interaction between two services (the credential store and credential store proxy), both of which are designed and implemented with security in mind.

Implementation concerns

In terms of implementation we consider that |FUSE| |xoce| is the best approach (|9P| |gihu| being the runner-up), because we have access to more information about the caller (such as process identifier, and knowing that we can easily obtain user and group information, executable, etc.)

The programming language is not important as long as there is a |FUSE| library available; it must however allow dynamic code loading.

Security concerns

The set of hard to solve security-related issues are briefly presented in what follows.

How the credential store service obtains the encryption key?

Basically in a cloud environment this is the weakest link, and no fully secure solution exists. One possibility is to convey, via the so called "user-data", the private key used to decrypt the credential data obtained from the general purpose store. Another possibility is to use a |HSM| that provides access to operations on such a private key; however such a solution is prohibitively expensive.

How to secure the communication between the credential store service and credential store proxy?

The obvious solution is a |TLS|-based communication channel with both client and server certificate-based authentication. However in such a case the problem is transformed into how to convey the required private keys to the two entities, which can be solved in a similar fashion like the previous problem.

How to enforce access policies to the credentials?

One potential solution is to encode, besides the actual credential data, also an access policy which states who is able to obtain access to that data. Such a policy can then be enforced by the credential store service, based on the identity of the credential store proxy (which is taken to be either the client public key obtained from the |TLS| negotiation, or a special attribute thereof.) Moreover such policies can be further conveyed, through the proxy, to the credential manager, which can further narrow down the kind of processes that can execute operations on them.

Implementation concerns

Although not many implementation details have been ironed out, there already exists previous work, namely secstore also from the |Plan9| ecosystem |zoti|.