0

In the SPIFFE specification it is stated that

Since a workload in its early stages may have no prior knowledge of its identity or whom it should trust, it is very difficult to secure access to the endpoint. As a result, the SPIFFE Workload Endpoint SHOULD be exposed through a local endpoint, and implementers SHOULD NOT expose the same endpoint instance to more than one host.

Can you please explain on what is meant by this and how Istio implements this?

Dan Kohn
  • 33,811
  • 9
  • 84
  • 100
Pasan W.
  • 674
  • 2
  • 10
  • 23

1 Answers1

1

Actually, Istio mesh services adopt SPIFFE standard policies through Istio Security mechanisms using the same identity document SVID. Istio Citadel is the key component for secure provisioning various identities and provides credential management.

It is feasible in the near future to use Node agent within Istio mesh in order to discover relevant services via Envoy secret discovery service (SDS) API and this approach is very similar to SPIRE design.

The key concepts of SPIRE design, described in the official documentation, you can find below:

SPIRE consists of two components, an agent and a server.

The server provides a central registry of SPIFFE IDs, and the attestation policies that describe which workloads are entitled to assume those identities. Attestation policies describe the properties that the workload must exhibit in order to be assigned an identity, and are typically described as a mix of process attributes (such as a Linux UID) and infrastructure attributes (such as running in a VM that has a particular EC2 label).

The agent runs on any machine (or, more formally, any kernel) and exposes the local workload API to any process that needs to retrieve a SPIFFE ID, key, or trust bundle. On *nix systems, the Workload API is exposed locally through a Unix Domain Socket. By verifying the attributes of a calling workload, the workload API avoids requiring the workload to supply a secret to authenticate.

SPIRE promises to become the main contributor for workload authentication mechanisms, however so far it's on developing stage with desired future implementation on production deployments.

Nick_Kh
  • 5,089
  • 2
  • 10
  • 16
  • Are you saying Istio uses SPIRE internally? From the facts I've read Istio(security) and SPIRE are both implementations for the SPIFFE specification. Never is it mentioned that Istio uses SPIRE. – Pasan W. Nov 13 '18 at 16:56
  • Yes, you are right Istio implements SPIFFE standards through Istio Auth(Security), I was thinking about similarity between SPIRE design and Node agents in Istio, however I've added some information in my answer. – Nick_Kh Nov 14 '18 at 15:18
  • 1
    Istio does NOT expose the Workload API at all. Still it is SPIFFE compliant because the only requirement to be Spiffe compliant is to adhere to [this](https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md) doc which Istio does. – Pasan W. Nov 16 '18 at 10:46
  • So is there any way to access the SPIFFE ID or trust bundle for use in other parts of your app? – Joe J Mar 13 '20 at 00:47