In 2019, the Scytale team has continued to shepherd the SPIFFE and SPIRE communities towards building standards and tooling that support the service identity concept. Part of the Cloud Native Computing Foundation (CNCF), these projects have grown in popularity and seen an increasing number of contributions from engineering teams at Amazon, Bloomberg, Google, Pinterest, Square, TransferWise, Uber, Yahoo Japan, and more. 

These community-led innovations and contributions have enabled SPIFFE to authenticate to more types of software systems and improved the deployment, operability, and performance of SPIRE in large-scale environments. 

While numerous contributions were made throughout the year, here are thirteen key capabilities released in 2019: 

Authenticate to Service Mesh, Cloud Platforms, Databases, and more

Until recently, SPIFFE has primarily been used to secure communications between services identified by a shared SPIFFE identity provider (IdP). Now, you can use SPIFFE and SPIRE to enable strong trust between cloud-native services and other shared services—including databases, service meshes, and public cloud providers. Key enabling features include: 

  1. SPIFFE federation: This allows services in disparate domains identified by independent SPIFFE identity providers (such as SPIRE), to securely authenticate and communicate with each other.  Key use cases for SPIFFE federation include: 

    - Federation between multiple mesh implementations 
    - Federating trust across different domains within an organization

    A number of emerging projects and platforms have adopted SPIFFE. This includes Istio, SPIRE, Scytale Enterprise, and several service meshes, including NGINX (F5 Networks) and Grey Matter (Decipher Technology Studios). SPIFFE federation will enable service interoperability across all these distributed environments.  View this recent session from KubeCon to see how you can secure communications between meshes and beyond with SPIFFE federation
  2. OIDC federation: SPIRE now supports OIDC (OpenID Connect). With federation primitives built into SPIFFE and SPIRE, you can directly authenticate to OIDC-compatible validators, without having to generate or manage secrets. For example, a system running within an on-premise data center managed by SPIRE can now directly authenticate to cloud platforms like AWS, without sharing secrets or private keys. Here is a video that demonstrates this capability. 
  3. Database authentication: You can now use SPIRE-issued identities to directly authenticate to databases and other systems that support legacy x509 authentication. This approach negates the need for a secret store and instead relies on short-lived asymmetric keys. This approach can also provide traffic encryption. To learn more,  you can view this demo. 

    Ease of Deployment and Operability  
  4. Plugin infrastructure refactoring: This enables plugins to provide auxiliary services, such as health check, to the SPIRE core. You can also request services from the SPIRE core or use server-like telemetry. The Notifier Plugin was added as a result of this refactoring. This plugin detects certain events and then performs an action in response.  An example of this is the K8S Bundle notifier plugin, which resolves a bootstrapping problem within Kubernetes. It publishes the latest trust bundle to a K8S ConfigMap when the SPIRE server is started and the bundle is updated. 
  5. Registration API remote access: This allows remote software services to authenticate against the registration API via SVIDs. This enables greater deployment flexibility by allowing software services to manage registrations, even if these services are not running next to a SPIRE server.
  6. K8S workload registrar: This registrar automates the registration of K8S workloads on SPIRE when they are registered in Kubernetes. With this capability, you can interact exclusively with the Kubernetes API server to get SPIRE fully deployed and operational. View this link for more details
  7. Telemetry and logging: These capabilities have been significantly improved, helping engineers better track and troubleshoot performance issues in production environments. Several telemetry points were added, such as a SQL datastore plugin. In addition, existing points were audited, augmented, and labeled with meaningful descriptions.  In addition, key health and performance metrics from the SPIRE server can now be exported directly to Prometheus, Statsd, and DataDog.
  8. Upstream plugin for AWS Secrets Manager and AWS Certificate Manager: This plugin enables you to use AWS Secrets Manager or AWS Certificate Manager as an upstream signing authority for SPIRE-issued identities. This can improve your security posture since keys do not need to be stored on disk. 
  9. MySql support: Now, MySql can be used to store configuration data for the SPIRE server.
  10. Docker-based workload attestor: This capability enables you to use selectors based on Docker labels and the container's image ID.
  11. Improved documentation: These documentation enhancements help make it easier to get started on SPIFFE and SPIRE. Documentation now includes a guide for getting started with Kubernetes as well as use cases and case studies. You can find these on 

    Performance and Scalability Improvements 
  12. Nested SPIRE: This new capability enables you to organize your SPIRE deployment into a hierarchy in which one SPIRE server can deliver CA identities to a downstream SPIRE server. This enables you to segregate your SPIRE deployment so you can improve fault management and resiliency. 
  13. Performance improvements: The team has made several performance improvements, especially within the datastore plugin. These enhancements optimize database performance and speed up scale-related hot spots. 

A big thank you to all the contributors for keeping the momentum going with SPIFFE and SPIRE. We’re looking forward to even more contributions in 2020. Happy New Year!