BastionZero has been deliberately designed to work with ephemeral infrastructure. When we say ephemeral infrastructure, we mean compute resources that are created dynamically and destroyed as needed, rather than being persistent and long-lived. Despite this, even with ephemeral infrastructure, your engineering and DevOps teams may still require access to infrastructure to support debugging and forensics. Teams need to be able to work through production issues, react to security events, or observe the infrastructure as it interacts with production workloads. Luckily, you can use BastionZero for this.
A few days ago, Richard Barnes (from Cisco) and I submitted a new internet draft to the Internet Engineering Task Force (IETF)’s OAuth working group. (This is the very first step on the long road to publishing an RFC in the IETF internet standards process.) In the draft we introduce PIKA: Proof of Issue Key Authority, to solve a problem relevant to OpenPubkey, OpenID Connect (OIDC) and JWTs (JSON Web Tokens) in general. PIKAs allow us to cache and redistribute an OpenID Provider (OP)’s public keys. In this blog, I’ll introduce the OpenPubkey issue that led me to get interested and start working on PIKAs, explain what PIKAs are, and show how they allow OPs to provide long-lived bindings of public keys to identities. And why PIKAs apply to much more than just OpenPubkey.
When we first released OpenPubkey, it was interoperable with many OPs (like Google and GitHub), but not with all of them. In fact, when we started this project, there was an actual technological limitation that prevented OpenPubkey from working with certain OPs, including GitLab’s OP. And support for GitLab’s OP was one of our most requested features. Well, today I’m happy to announce that last week’s release of OpenPubkey v0.3.0 smashes through this limitation. OpenPubkey now interoperates with any OpenID Provider.
