Support host certificates

[alex]

We'd need to figure out how this would work, but if it could do host certs, that'd be swell.

[paultag]

@alex should we reopen #66 ? This was the driving thought behind that particular issue

[alex]

Maybe! I'd like to understand the workflow of host certs a bit more first:

• What fields do you need to fill in for a host cert
• How would you auth over those
• Should host certs be short lived? If so, how do we package that up for hosts.

[paultag]

My strong inclination would be to ignore all those issues by requiring them to be set as tags on the role that's been assumed to request the certificate, and provide a binary to run on a cron on the host, but something more complicated could be fun too!

…

On Sat, Mar 7, 2020, 2:18 PM Alex Gaynor ***@***.***> wrote: Maybe! I'd like to understand the workflow of host certs a bit more first: - What fields do you need to fill in for a host cert - How would you auth over those - Should host certs be short lived? If so, how do we package that up for hosts. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#120?email_source=notifications&email_token=AABAKX7VDTZSDYCUWJPIFH3RGKMXDA5CNFSM4LDSD5A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEDH5A#issuecomment-596128756>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAKX5JYZ6KZ2GCVT2KOA3RGKMXDANCNFSM4LDSD5AQ> .

[alex]

I don't think that's ignoring the issues, I think that's answering them!

[alex]

So, the challenge with using the role is that it means you need a role per instance, which seems painful.

The other option would be to require providing the signed instance metadata document and getting tags from the instance itself. This is more complex though.

So maybe we need to do both? Is there some better option?

[alex]

Oh, one other note: assume-role does contain the instance ID in the "comment" position. So you could split the difference by having a tag on the role which says "you can trust the comment to be an instance ID".

Is that too subtle?

[paultag]

You can't trust that - it's a user provided free text field that you can set via the API that defaults to the instance id when not provided by go/python. I made that mistake once already, and triggered a misissuance after we figured out we can control that string 😬

…

On Sat, Mar 7, 2020, 4:15 PM Alex Gaynor ***@***.***> wrote: Oh, one other note: assume-role *does* contain the instance ID in the "comment" position. So you could split the difference by having a tag on the role which says "you can trust the comment to be an instance ID". Is that too subtle? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#120?email_source=notifications&email_token=AABAKX4CY6VFIJZGI33BXDLRGK2N7A5CNFSM4LDSD5A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEFRYA#issuecomment-596138208>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAKX2TIYNEFCRZXTRZLJ3RGK2N7ANCNFSM4LDSD5AQ> .

[alex]

Ooof. I didn't realize it was user controlled even for EC2 launches. Welp, nevermind.