To support ssoca being a CA for VM-specific operations, allow clients to run on VMs and authenticate with their AWS Instance Identity documents and then the server can provide a certificate based on that metadata.
Also support the server being (optionally) configured with AWS credentials for retrieving additional metadata from EC2 about the instance and include it in the token for additional authorization checks. For example, to require specific tags to be present.
Specific use cases:
Allowing VMs to SSH to other VMs without any pre-provisioned credentials via SSH CA authentication.
Allowing VM-specific OpenVPN connections to a remote server without sharing credentials.
VMs presenting their own, VM-signed TLS certificates in a cluster.
At some point, might need to consider ssoca supporting multiple auth providers. For the short term, multiple servers could be used (with intermediate CAs to distinguish between certs).
If this turns out to be practical, would want to make sure usage of this as a library is trivial.
Kind of related to SPIFFE/Spire. They seem specifically focused on SVIDs and application-level precision and it requires a separate server/client infrastructure. Because of that, I think there's still room for this more general auth mode which goes directly from identity documents to a certificate. In theory, I imagine an additional auth service which is based purely on SPIFFE for those more complex environments.
To support ssoca being a CA for VM-specific operations, allow clients to run on VMs and authenticate with their AWS Instance Identity documents and then the server can provide a certificate based on that metadata.
Also support the server being (optionally) configured with AWS credentials for retrieving additional metadata from EC2 about the instance and include it in the token for additional authorization checks. For example, to require specific tags to be present.
Specific use cases:
Related futures: