-
Notifications
You must be signed in to change notification settings - Fork 9
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
Support host certificates #120
Comments
Maybe! I'd like to understand the workflow of host certs a bit more first:
|
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>
.
|
I don't think that's ignoring the issues, I think that's answering them! |
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? |
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 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>
.
|
Ooof. I didn't realize it was user controlled even for EC2 launches. Welp, nevermind. |
We'd need to figure out how this would work, but if it could do host certs, that'd be swell.
The text was updated successfully, but these errors were encountered: