spiffe/spiffe-helper

The SPIFFE Helper is a tool that can be used to retrieve and manage SVIDs on behalf of a workload

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].

spiffe-helper's Issues

Missing LICENSE

What is the LICENSE of this project?

Proposal: Support JWT

Would be great if this helper supported grabbing a JWT and making that available to the app. I propose adding a couple of fields to the config spec, jwtPath where the file should be written (this would respect the cert_dir already there, and jwtENV, an environment variable to inject the JWT into.

Signal handling would remain the same, etc...

If folks agree with the proposal I'm happy to implement and PR.

How do I build, install and use this?

Why would I want to use this? How do I build, install and use this utility? What configuration options are available? This should all be included in our README.md.

suggestion: systemd integration

It would be nice if the tool had integration with systemd to enable launch / reload via systemd.

Its saves sysadmins from "reinventing the wheel" and un-necessary DIY maintenance dependencies.

Also pretty much all third-party packages will install a systemd service. So that's more sysadmin work to remove the systemd service.

For example, PostgreSQL, install via official package. It installs a systemd service. All configuration (e.g. where to find SSL certs) is done in /etc/postgresql, so sysadmins don't need to touch the maintainer's systemd service. It would be good to point the /etc config at the spiffe certs location and spiffe-helper calls systemd.

Update default config path

Right now its justhelper.conf in the same directory as the binary. Should be something like /opt/spire/conf/spiffe-helper/helper.conf

Validate configuration file

Current config file does not apply proper validations,
review code and add validations if required

Kubernetes Sidecar Usecase

It would be great if spiffe-helper could be used as a sidecar under Kubernetes.

This would require two different modes of operation to function well.

1. a new flag for running in job mode. This would block until it could fetch the cert/key/ca, and then exit 0 on completion.
   This would run as a k8s initContainer and ensure initial cert/key/ca creation before the workload starts.
2. a new flag specifying a pid file. Instead of running a command and then signaling the process it forked, it would just notify the pid that preexists as specified in the file. This would enable it to signal a process in a different container, in the same pod.

A container image would also be needed. Requested here: #107

Add plugins for reload notifications

In current implementation we supports sending signals or running an script in order to communicate
process that a SVID was rotated, but now we have windows where signals is not an option..
I was thinking about this and we may be able to add plugins that are used to send notifications to process (for example postgres or mysql) about there is a new SVID and they may rotate.

For now I was thinking in:

• SignalNotiication: Send a signal to an specific process
• PostgresNotification: Notify notify postgres to reload certificates
• MySqlNotification: Notify MySQL to reload certificates
• BashNotification: Run a bash script that can be used to apply changes or notify processes

The advantage is that we may be able to support different applications without depending only on signals or bash scripts.

add support for jwt-svid

Support Workload RSA Private Key

It is possible to configure the Spire agent to generate private keys using RSA format instead of default ECC (see property workload_x509_svid_key_type). Unfortunately spiffe-helper assumes all private keys to be of type EC (see function writeKey at line 224. I don't know if correct but perhaps the type used can be determined from the certificate instead?

Container image

There needs to be a container image for this so it can be more easily used in containerized environments.

Why EC certs and not RSA?

I'm just relaying the question while I was investigating into the direction of getting EC cert support to the fundamental rust ssl libraries, I can't give a solid answer myself:

rustls/rustls#409 (comment)

Support multiple JWTs

Something I missed when reviewing #85 is that if you need multiple JWT paths because you have JWTs for more than one audience, there's no way to do this currently.

Add ability to exit on successful retrieval of JWT SVID

spiffeid hint

When the workload has multiple spiffeid's there needs to be a way to specify a hint so the desired identifier can be used.

Support for federated mode

In federated mode, peer CA bundles are stored as separate files from the local CA bundle, svid key, and svid cert. Briefly looking at the code, it seems to be hard coding only those 3 files and not taking into account of any additional bundle files in federated mode. Can someone verify if this is the case?

Job mode

Feature request.

A flag should be added to switch the run mode to behave more like jobs. Instead of a long running process that gets signaled on updates, run the command to completion, and on updates, run the command again.

Update configuration file to snake case

Config file is using camel case, but in spire we are using snake case,
We may update it to snake format to be consistent

JWT SVIDs are missing tests in sidecar_test.go

Append certificate and key to support ghostunnel keystore argument.

Why is this needed?
To support ghostunnel keystore parameter for a single PEM file containing both the certificate chain and private key, spiffe-helper should be able to append certificate and key pem when configured with same filename.

Document default values in main readme

Right now it just shows example values.

Update helper to use the new workload API

Support docker image

I think it would be useful to run SPIFFE Helper as a sidecar of Kubernetes pod to manage SVID.
And I think that the image should be published as one of official images as below:
https://console.cloud.google.com/gcr/images/spiffe-io

Give me feedback. If it is OK, I will create a PR.

Set up integration test for mysql

Switch to structured logging

Right now we are using go-spiffe/v2 logger package which is just a wrapper for the standard golang log package. We should switch to zap, zerolog, or one of the other structured logging libraries.

error executing process while using empty cmd

While using cmd = "", spiffe-helper keeps showing:

unable to signal process: error executing process: 
fork/exec : no such file or directory

< helper.conf with cmd = "" >

< helper.conf with cmd = "echo" >

Support windows

Update Makefile to allow windows support, and update CI to build windows binaries

static builds

The release binaries are linked against glibc, so it doesn't work in a static container or on alpine

Could they be produced statically instead so they work on the widest number of platforms?

Remove camel case config

Add default socket path

Add default socket path, using the same than spire (/tmp/spire-agent/public/api.sock)

Re-name this project as `spiffe-helper`

This tool describes itself as the "SPIRE" sidecar, but wouldn't it work with any platform that implements the SPIFFE API? If so the project description and documentation should be updated accordingly.

Change SPIRE_AGENT_ADDRESS to SPIFFE_ENDPOINT_SOCKET

SPIFFE standard already specifies SPIFFE_ENDPOINT_SOCKET as the name for the env var.

Clean examples

Clean examples and verify still working

SPIFFE Helper releases

Add automation to create images when releasing spiffe-helper,

Acceptance criteria:

• use scratch image as base
• images are pushed into ghcr.io

Optional:

• Release windows images

Add github action as CI

Currently spiffe helper is using travis, we must move to gh action and add validations

Setup integration test for simple example

Setup integration test for postgres

Add support for JWT extra audiences

Documented here: https://github.com/spiffe/go-spiffe/blob/main/v2/svid/jwtsvid/source.go#L12