Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spiffe/spire to proof: running on aws and in memory encrypted context #2667

Open
1 task
hpvd opened this issue Nov 30, 2023 · 2 comments
Open
1 task

spiffe/spire to proof: running on aws and in memory encrypted context #2667

hpvd opened this issue Nov 30, 2023 · 2 comments

Comments

@hpvd
Copy link

hpvd commented Nov 30, 2023

Use case

Originally it is about things running within kubernetes, but I think it's worth to share - maybe this idea can somehow be adapted for hardening constellation:

We can now assert two statements are true, our agent runs:

  • On an AWS EC2 machine
  • In a memory encrypted context

https://control-plane.io/posts/spiffe-confidential-computing-august-2023/

spiffe intros:
https://spiffe.io/
https://github.com/spiffe/spire
https://control-plane.io/posts/spiffe-keystone-of-cloud-native/

and the spiffe plugin:
RFC: SEV SNP Node Attestation Plugin
spiffe/spire#4469

Describe your solution

No response

Would you be willing to implement this feature?

  • Yes, I could contribute this feature.
@3u13r
Copy link
Member

3u13r commented Dec 4, 2023

Hello,

the following points are already verified by Constellation:

We can now assert two statements are true, our agent runs:

On an AWS EC2 machine
In a memory encrypted context

This is because AWS is enrolled with AMD to use a VLEK instead of a VCEK (https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf Section 3.6 and https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snp-attestation.html).
If you create a Constellation on AWS this is verified during constellation apply. To have a look at the VLEK certificate you can execute constellation verify. Sadly, AMD's specification is a bit behind their implementation. If you take the raw X.509 and have a look at the extension with OID 1.3.6.1.4.1.3704.1.5 it states CN=cc-eu-west-1.amazonaws.com.

Therefore, you already can prove that the VM is located in a specific AWS region. You cannot bind the name of the EC2 instance to the attestation but you have a better TCB since you don't have to reply on AWS' IMDS API.
Does this already has the security properties you need? It would be great to have a clear picture of your requirements.

Also, with Constellation being a Kubernetes distribution pinning against concrete VM names sounds counter intuitive at first since e.g. on a Constellation upgrade all the nodes are replaced.

@hpvd
Copy link
Author

hpvd commented Feb 13, 2024

just an example on this topic in general: why and how uber uses spiffe/spire:
https://www.uber.com/en-DE/blog/our-journey-adopting-spiffe-spire/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants