Feature Request: NodeAttestor based on AWS "IAM Role" authentication

[hellerda]

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!

• Version: 1.2.0
• Platform: Fedora 35 or Amazon 2 Linux
• Subsystem: Agent NodeAttestor

[evan2645]

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!

[evan2645]

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?

Another consideration is whether or not to trust the "RoleSessionName" associated with an IAM Assumedrole, referred to as "inferencing" in the Vault doc.

Any idea what the RoleSessionName value is in the case of non-EC2 resources, e.g. a k8s pod running in fargate?

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?

I think this is how the mechanism works to begin with - the node to be attested pre-signs a request to STS GetCallerIdentity, which can then be replayed to AWS by the server to verify validity. We could try to sneak a nonce into the request somehow to better know about freshness, but it still boils down to "anyone who has a credential for the IAM role in question"

In the end, we're open to supporting another AWS node attestor if there are enough folks for which that approach is better, and/or if we can find a clear path to supporting non-EC2 AWS services using it

[github-actions]

This issue is stale because it has been open for 365 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 30 days since being marked as stale.