Serverless support: disk plugin

[amartinezfayo]

Explore the possibility to implement a plugin that provides support to store issued identities on disk.
Storing issued identities on disk is something that may be useful in a variety of scenarios, particularly to improve the integration of SPIRE with systems that are not SPIFFE-aware.
It also provides the benefit of having a simple plugin implementation that can be used to exercise the functionality of externally storing identities in SPIRE through integration tests.

This issue tracks the exploration of the need of the plugin + its possible implementation.

Depends on #2067.

[amartinezfayo]

The possibility to introduce a disk-based SVIDStore plugin has been explored in #2647.
When a new built-in plugin is being introduced, it's crucial to analyze the different usability patterns and how the plugin will behave and be operated. A fair amount of time was spent looking at different implementations to satisfy the use cases.

The main use case considered was a scenario where SPIRE Agent is deployed alongside a non SPIFFE aware workload that can use X509-SVIDs for authentication.

Having SPIRE Agent writing sensitive data like private keys and at the same time make it easy to be consumed by workloads in a secure way resulted in a challenging problem. The introduction of selectors to specify the group ownership of the files and directories created was explored to solve this. The main drawback of this approach is that in order to be able to set the ownership, the plugin requires that the user that runs SPIRE Agent is a member of the group specified through the selector. This implies that the operator needs to keep consistency between the registration entries and group membership of the system, which can be very problematic.

Additionally, workloads need to be able to traverse through the directory hierarchy to reach the written files, which means that workloads need to have execute permissions in the directories, either granted by the group membership or by having world-executable directories. To avoid having to provide world-executable permissions, the plugin could be restricted to allow only a single level of subdirectories under the base directory configured to store the files.

The problem of the need of syncing between the selectors in the registration entries and group membership in the system can be avoided if SPIRE Agent is executed as root, which obviously comes with its own bad consequences.

Considering that having a straightforward and consistent experience across different deployments is a primary goal of any plugin, and that the work and research done evidences that the challenges exposed will most likely be translated in operational complexity and problems, it was concluded that at this point in time we don't have a design and possible implementation of the plugin that can provide a seamless experience to SPIRE users.
As a result of this, #2647 is being closed.

[azdagron]

Closing this. See the discussion above.