SPIFFEは、Zero Trust Networkを実現するための認証機構用APIとして生まれたらしいです。
何か、他のリソースへアクセスする機能を持ったものをWorkloadと呼び、そのWorkloadに対して、検証可能なTokenを付与することが主な責務です。
Workloadとして例えば、VM、container、functionなどが考えられます。
アクセスされる側もまたWorkloadの一つです。
あるWorkloadは、他のWorkloadにアクセスする際、Tokenをもって自分が何であるかを示します。 またアクセス先のWorkloadからもTokenを示してもらい、正しいアクセス先であることを知ることができます。
Tokenを発行するのがSPIFFEであり、Tokenを検証するのもSPIFFEです。 という感じです。
パブリッククラウドを利用しているとI AMという機能がありますが、それをGenericにしたものという理解は大体あってそうな気がしました。
ものすごい雑な理解だけど「EC2 インスタンスに credential を持たせたくないので IAM Role を使いましょう」のジェネリック版みたいに使えると思っておけばいいだろうか？ #spiffejp
— チェシャ猫 (@y_taka_23) May 14, 2019
SPIFFEでは、JWTとX.509の2つのTokenが今のところ策定されているので、Workload間で安全な通信を行うこともできるようになっています。
ではSPIFFEの参照実装であるSPIREはどうやってWorkloadに適切なTokenを割り当てるのかというと、そこはPlugin機構になっており、KubernetesやAWS、GCPなどのPluginが存在していて、 ようするにWorkloadの生成元からその情報をもらうということを行っています。
また、KubernetesやAWS、GCPそれぞれにSPIREを動作させ、それらの間でfederationすることで、相互にTokenの検証ができるようになります。
これができると、マルチクラウド、マルチクラスタ間で、Workload同士が互いに認証でき、また、セキュアな通信路で通信することができます。
SPIRE自体は、認証の大本となる情報を直接は保持しない作りになっているのもよいところだと思います。
