What Is SPIFFE and How Does It Impact Machine Identities? | #cloudsecurity


What Is SPIFFE and How Does It Impact Machine Identities?
brooke.crothers
Thu, 05/12/2022 – 13:27

Why SPIFFE was created

Protecting the network isn’t what it used to be. At the advent of the internet, there were a mere 213 servers in existence. Now, new software is designed using microservices architectures and deployed to the cloud, making it impossible to draw a ‘perimeter’ around it and secured via traditional methods like firewalls and network segmentation.

Additionally, the number of software vulnerabilities is overwhelming, and chances are high that every piece of software has some. And employees themselves are a liability, prone to human error, phishing, malicious activity and poor judgement. It is hard to justify a security architecture that is exposed to so many variables. Plus, it hardly makes sense to enforce a perimeter when employees are accessing resources from so many different networks. As far back as 2014, Google released a case study about the BeyondCorp security architecture, making the case for a security architecture that could exist in a world without a traditional security ‘perimeter’.

As we evolved further into the digital age, the walls came down, and the number of identities continued to grow exponentially. As the SPIFFE eBook Finding the Bottom Turtle states, “physical identity verification (common with walls and guards), became virtualized through securely exchanging and managing keys, credentials, and tokens,” And the problem was exacerbated as resources migrated to the cloud—the acceleration brought on by DevOps and the move to microservices and the number of unmanageable identities. 

That is where SPIFFE comes in.

SPIFFE solves the problem of workload authentication in diverse environments

Modern architecture is framed in a multi-layer stack. Conceptually, you have your platform layer at the bottom, a host layer on top, and individual processes on top of the host. How do you identify workloads within that stack? Traditionally, you would:

  1. Identify by platform: That’s fine but only works within the platform and is not generally platform agnostic. Therefore, this does not play well with other platforms. Something is needed that can cross over.
     
  2. Identify by Host: There are similar problems. This is one of the most common forms of identifying resources and doing network security but the problem grows as the network does, making the list of IP addresses grow ever longer and more difficult to manage.

Either solution only partially solves the problem, and in some ways causes many more challenges.

According to SPIFFE, “Distributed design patterns and practices such as micro-services, container orchestrators, and cloud computing have led to production environments that are increasingly dynamic and heterogeneous. Conventional security practices (such as network policies that only allow traffic between particular IP addresses) struggle to scale under this complexity.” Therefore, “a first-class identity framework for workloads in an organization becomes necessary.”

Principles of SPIFEE

“Access control, secrets management, and identity are all dependent on each other,” states the SPIFFE eBook. For that reason, “managing secrets at scale requires effective access control; implementing access control requires identity,” and “proving identity requires possession of a secret.” Protecting that secret requires protecting the one below it, and so on. This is like the woman who told a philosopher that the world rests on the back of a giant turtle. When asked what that turtle rests on, she replied “It’s turtles all the way down!” Finding the ultimate ‘bottom turtle’ is the principle upon which SPIFFE is built.

This turtle represents ground-zero for security in the data center and in the cloud, and foundationally supports all the others. SPIFFE helps you find the bottom turtle within your organization or the one security common denominator that can allow a properly authenticated asset to access other resources across any environment.

How does SPIFFE work?

“SPIFFE is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments,” states the documentation. Adopting SPIFFE allows you to mutually authenticate systems wherever they are running. It authenticates with cryptographic identifiers called SVIDS, via a workload API, allowing authorized processes to then use these identifying documents when authenticating to other workloads. This can be done by signing and verifying a JWT token, or via a TLS connection.

SPIFFE works by identifying workloads at the process level, skipping the problems inherent with traditional models. Instead of saying “Host #5 can communicate with Host #6,” you are able to specify, “this specific process can communicate with that one.” That way, identity is not tied to location but to the asset. The SPIFEE protocol for identifying individual workloads is broken down into three parts:

  1. Name it. Provides a SPIFFE ID to the specific workload, or a “username for workloads”.
  2. Prove it. Authenticates the SPIFEE ID with a SVID, or SPIFEE Verifiable Identity Document (like an X.509 certificate) that has been signed by a valid Certificate Authority.
  3. Get it. This is just the workload API that provides the SVIDs (certificates) to the workload in the first place.

So now identity is attached to the process, instead of the layer, allowing you to:

  • Automatically secure microservices with X.509 PKI, Envoy, or JWT
  • Extend service mesh enterprise-wide without sharing keys
  • Securely authenticate to common platforms without API keys or platforms
SPIFFE and machine identity management

SPIFEE relies on mutual TLS authentication, which requires an individual X.509 certificate to be spun up for each new process needing to be verified. Since SPIFFE was invented to keep up with DevOps and the millions of microservices it creates, the number of certificates needed to be managed now becomes significant.

How will you keep track of every single digital certificate and their corresponding keys? How will you know when they expire, the Certificate Authority that issued them, or their exact location within your multi-platform, multi-cloud environment? And why does it matter?

It matters because each certificate is a liability if not handled properly. A misconfigured or expired certificate could result in an outage, which leaves you wide open to a data breach. With IBM placing the cost of an average data breach at over $4 million, that is not a desirable option. Unfortunately, with all the good SPIFFE provides, it is only able to completely benefit your organization when the thousands, perhaps millions, of digital certificates it generates are able to be controlled and managed effectively.

A good machine identity management platform can provide you with the ability to automatically provision, configure and deploy X.509 certificates across multiple environments at the rate of SPIFFE capabilities. It will give you full visibility into the location of your certificates no matter where on your ecosystem they reside—in the cloud, in on-prem resources, within virtual machines or across multiple containers—and present you a full configuration status update within a single control-panel dashboard.

Jetstack Secure is a cloud-native machine identity security platform designed to automatically control and manage X.509 configuration across Kubernetes and OpenShift clusters, wherever in your environment they might reside, giving you a management solution that can keep pace with SPIFFE protocols. Combining a machine identity management platform with SPIFFE will enable you to secure more diverse machines across more diverse networks and make the cryptographic certificates that underpin your security architecture an asset, not a liability.

 
Related Posts



Original Source link




Leave a Reply

Your email address will not be published.

67 − = fifty seven