spiffe/spire-plugin-sdk

SPIRE Plugin service definitions and scaffolding

The Secure Production Identity Framework For Everyone (SPIFFE) Project defines a framework and set of standards for identifying and securing communications between application services. At its core, SPIFFE is:

• A standard defining how services identify themselves to each other. These are called SPIFFE IDs and are implemented as Uniform Resource Identifiers (URIs).

• A standard for encoding SPIFFE IDs in a cryptographically-verifiable document called a SPIFFE Verifiable Identity Document or SVIDs.

• An API specification for issuing and/or retrieving SVIDs. This is the Workload API.

The SPIFFE Project has a reference implementation, the SPIRE (the SPIFFE Runtime Environment), that in addition to the above, it:

• Performs node and workload attestation.

• Implements a signing framework for securely issuing and renewing SVIDs.

• Provides an API for registering nodes and workloads, along with their designated SPIFFE IDs.

• Provides and manages the rotation of keys and certs for mutual authentication and encryption between workloads.

• Simplifies access from identified services to secret stores, databases, services meshes and cloud provider services.

• Interoperability and federation to SPIFFE compatible systems across heterogeneous environments and administrative trust boundaries.

SPIFFE is a graduated project of the Cloud Native Computing Foundation (CNCF). If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF.

SPIFFE Standards

• Secure Production Identity Framework for Everyone (SPIFFE)
• The SPIFFE Identity and Verifiable Identity Document
• The X.509 SPIFFE Verifiable Identity Document
• The JWT SPIFFE Verifiable Identity Document
• The SPIFFE Trust Domain and Bundle
• The SPIFFE Workload Endpoint
• The SPIFFE Workload API
• SPIFFE Federation

Getting Started

• spiffe: This repository includes the SPIFFE ID, SVID and Workload API specifications, example code, and tests, as well as project governance, policies, and processes.
• spire: This is a reference implementation of SPIFFE and the SPIFFE Workload API that can be run on and across varying hosting environments.
• go-spiffe: Golang client libraries.
• java-spiffe: Java client libraries

Communications

• Slack (Join here).
• [email protected] (View or join here).
• [email protected] (View or join here).
• [email protected] (View or join here).

Contribute

• CONTRIBUTING
• GOVERNANCE

SIGs & Working Groups

Most community activity is organized into Special Interest Groups (SIGs), time-bounded working groups, and our monthly community-wide meetings. SIGs follow these guidelines, although each may operate differently depending on their needs and workflows. Each group's material can be found in the /community directory of this repository.

Name	Lead	Group	Slack Channel	Meetings
SIG-Community	Umair Khan (HPE)	Here	Here	Notes
SIG-Spec	Evan Gilman (VMware)	Here	Here	Notes
SIG-SPIRE	Daniel Feldman (HPE)	Here	Here	Notes

Follow the SPIFFE Project You can find us on Github and Twitter.

SPIFFE SSC

The SPIFFE Steering Committee meets on a regular cadence to review project progress, address maintainer needs, and provide feedback on strategic direction and industry trends. Community members interested in joining this call can find details below.

• Calendar: iCal or Browser-based
• Meeting Notes: Google Doc
• Call Details: Zoom Link

To contact the SSC privately, please send an email to [email protected].

spire-plugin-sdk's Issues

Add a README

As a member of the SPIFFE community, I have a pretty good idea what this repo is about just by the name. As a consumer, I want more details, including, but not limited to:

• intended use
• supported use cases
• unsupported use cases
• examples
• troubleshooting guide (e.g. grpc version issues, etc.)

Setup GitHub Actions workflows for this repository

In #23 @rturner3 fixed up the dirty check function in the Makefile, but noted in Slack that we don't have any worklows that enforce this

We should be able to ensure that, at a minimum, everything compiles and updated protos have been regenerated. To start, the workflow should be run for each PR, and each change to the main branch

Incorrect attestation flow wording in server nodeattestor.proto comments ?

The comments at the top of server/nodeattestor/v1/nodeattestor.proto are perhaps misworded ?

2. SPIRE Server sends a request containing the attestation payload received from the agent.

Should this not be "receives a request" and remove "received" (so the end reads 'received from the agent").

4. The plugin returns the attestation results to SPIRE Server and closes the stream.

Should this not be "to Spire Agent" ?

Clarification required about AgentAttributes in node attestation

According to the comments in the code:

On the agent side (agent/nodeattestor/v1/nodeattestor.proto) we are told that spire agent awaits challenges from the server, and if no further challenges are received, can close the stream.

However, on the server side (server/nodeattestor/v1/nodeattestor.proto), we are told that AgentAttributes is "Required as the last response.".

It is therefore not clear how this fits in with the agent. Becuase if the agent closes the stream when it receives no further challenges, the server will surely be unable to send AgentAttributes ?

Or does this magically happen in the background somewhere ?

Whichever way, more clarification needed, please !

Improvement on documentation for authoring plugins

We don't have examples for authoring different kinds of plugins that are defined here. This issue proposes an improvement in the Authoring documentation section to have at least one actual example of plugin implementation for each plugin type (agent and server). I'm willing to work on this 😄

Provide an example plugin implementation that embeds an upstream plugin

It's common to want to provide custom selectors during node attestation without wanting to fork existing upstream plugins. The recommended way to do this is to embed the upstream plugin (i.e. wrap it), and inject custom selectors when Attest is called. That said, we don't have any good examples of how to do this.

This repository should provide, at a minimum, some docs and examples on how to do this.