evan2645
commented
2 years ago Hey @hellerda thank you for opening this, it is a question we get from time to time.
TL;DR: we would love to improve the security of our cloud-based node attestors and are open to exploring new flows/possibilities. We've had a look at this one before and the conclusion was more or less "six one way half dozen the other", but we're happy to re-open the conversation if we've missed something important.
I am happy to have an issue on this now (what was previously Slack conversations etc) so please ask any questions you may have.
I know this was discussed in the context of Serverless Pull, but it seems valuable to have as a simple NodeAttestor as well. It could support Agents running in any AWS runtime, not just EC2.
Part of "node attestation" in SPIRE is an assumption that we can "prove" a node identity, one which is unique to the specific system or piece of hardware being attested. In EC2 this makes good sense because we have instance IDs. When you start talking about IAM roles, things get a lot more hazy. Who or what exactly is being attested?
For the serverless use case, we were considering the introduction of a new set of APIs and possibly plugins to drive a more general credential exchange process, in which exchanging an IAM credential for a SPIFFE credential would be a good fit. It is a much larger work, though something that I think we're still open to.
There are some pitfalls mentioned here (https://googleprojectzero.blogspot.com/2020/10/enter-the-vault-auth-issues-hashicorp-vault.html), along with a couple of CVE, but it looks like this has been solved. But it points out the server-side code would have to be done carefully to avoid any vulnerability.
Yes .. it is definitely more complicated. We also were not able to see any major security gain, only that the documents used in the flow are more aggressively time bound. While an improvement, it doesn't really move the needle much in terms of SPIRE security posture.
Another consideration is whether or not to trust the "RoleSessionName" associated with an IAM Assumedrole, referred to as "inferencing" in the Vault doc.
This is a big deal and it pokes a fairly large sized hole into our assumptions about node attestation. Normally you can use RoleSessionName to get e.g. the EC2 instance ID of the entity that made the request .. however, this field can actually be controlled by anyone with the ability to assume one of the roles you use in your instance profiles. While it can be prevented through configuration, it is very surprising node attestor behavior.
But since SigV4 provides as way for the caller to "sign", I wonder if some "challenge" could be put to the caller, to allow it to sign a nonce, or some other data proving currency and verifying the caller's identity?
If we can do this with an asymmetric key pair, and we can somehow prove the identity of the instance that owns that keypair, then this would be very interesting improvement!
github-actions[bot]
In the discussion of Serverless support (issues #558, #1784, #1843) there were several mentions of the "IAM Role" authentication method based on SigV4-signed GetCallerIdentity request, as developed by Vault (https://www.vaultproject.io/docs/auth/aws), and used by Kubernetes (https://github.com/kubernetes-sigs/aws-iam-authenticator).
I know this was discussed in the context of Serverless Pull, but it seems valuable to have as a simple NodeAttestor as well. It could support Agents running in any AWS runtime, not just EC2. It could also support on-prem nodes, as long as they have access to AWS API and have some AWS Identity configured to start.
There are some pitfalls mentioned here (https://googleprojectzero.blogspot.com/2020/10/enter-the-vault-auth-issues-hashicorp-vault.html), along with a couple of CVE, but it looks like this has been solved. But it points out the server-side code would have to be done carefully to avoid any vulnerability.
Another consideration is whether or not to trust the "RoleSessionName" associated with an IAM Assumedrole, referred to as "inferencing" in the Vault doc. But since SigV4 provides as way for the caller to "sign", I wonder if some "challenge" could be put to the caller, to allow it to sign a nonce, or some other data proving currency and verifying the caller's identity?
Would it be useful to implement this as a standard NodeAttestor? Or is there sufficient functionality in the existing NodeAttestors, to support agents running in Amazon ECS/Fargate or Lambda?
Thanks!