Provisioning token to the workload

[edoardogiordano]

Following the discussion on the mailing list, I wanted to give my take on the different options to provision the workload with the token. Maybe we can use it to start the discussion before starting the PR.

Identity provision mechanisms: Current workload systems mainly rely on three solution to provide the Identity to a running workload:

1. Environmental variables: they provide the easiest solution to inject the container with information, but presents some drawbacks:
   • Static nature: the information are injected when the container is started and cannot be modified at runtime
   • Access control: restricting access to environmental variable is more challenging and are usually exposed inside logs and to debugging tools ENV variables should be used with short-live credentials, when simplicity is a requirement.
2. Volumes, i.e., Projected volumes as named in Kubernetes, offer the possibility to pass information through the file-system. This allows to inject dynamical credentials, rotate them and perform a better access control. The main drawbacks of this solution is the additional complexity. Indeed, the solution requires multiple configurations:
   • The files need to have a proper access control definition, to prevent the unauthorized access of a different process
   • The mounted volume needs to be correctly isolated to prevent a compromised container to be able to gain more control over the host machine
   • The additional burden of monitoring the different workload to maintain valid credentials in each container (this last element can be handled by the orchestrator). The main advantages of this approach, with respect to the previous one, is in a better access control of the resource and the possibility to rotate the credentials without the need to restart the container. This solution fits well when multiple different process in the container need to access the credential's file.
3. Loopback interface relies on a local endpoint, usually exposing an HTTP or a gRPC interface, to provide the identity information to the workload. This solution, present additional advantages to the cost of complexity:
   • Limiting the exposure of the credential thanks to the properties of network isolation in the loopback interface.
   • It also allows an on-demand fetching and rotation of the credentials. Nevertheless, there are also some drawback in using this solution:
   • The dependency on the network stack, which may differ based on the host machine, and creating a one-for-all solution might require additional code.
   • The additional latency due to the request and the increase of the operational overhead. This approach should be preferred in conjunction with side-cars/agents and centrally managed identities solutions for application that requires dynamic credentials.

[b3n3d17]

1. Environmental:

I mostly agree with this. Although are usually exposed inside logs can you provide an example of this statement.

In theory it is also possible to rotate Environment Variables.

2. Volumes:

• and perform a better access control. based on DAC (uid and gid) or protect with additional MAC methods such as SELinux
• The files need to have a proper access control definition, to prevent the unauthorized access of a different process or using different mount namespaces to prevend unauthorizted processes from accessing the file.

3. UNIX Domain Socket/Loopback interface/Magic (Link-Local) Address (e.g., AWS Metadata Service 169.254.169.254)

• UNIX Domain Socket: I think we should mention this as well as

  • spiffe.io/docs

• lo and Link-Local addresses

@edoardogiordano wdyt?