discussion: v2 api?

[paultag]

Currently, we PUT an ssh key, in the authorized key format. This is very easy to implement and it makes me feel very satisfied in the API call. Send a public key, get a certificate.

I think it may be time to tweak the API though, perhaps sending JSON to the endpoint instead.

In particular, I'd like to change the API to look like:

{
    "public_key": {
        "type": "ssh-*",
        "bytes": "base64byteshere==",
    },
    "certificate_key_id": "user@host",
    "certificate_type": "user|host",
}

or perhaps

{
    "public_key_bytes": "base64byteshere==",
    "certificate_key_id": "user@host",
    "certificate_type": "user|host",
}

to allow Hallow to issue Host Certificates too.

Alternatively, we can set this in http X-Hallow-* headers. I like that slightly less.

As a stop-gap, we can support both inputs by checking the first byte, since { is not a valid ssh key type, and then drop the old format after we're sure all client binaries out there have been forward-ported.

[alex]

What's the use case for host certs. Specifically, what does it use for principal?

…

On Sat, Feb 8, 2020, 10:06 PM Paul Tagliamonte ***@***.***> wrote: Currently, we PUT an ssh key, in the authorized key format. This is very easy to implement and it makes me feel very satisfied in the API call. Send a public key, get a certificate. I think it may be time to tweak the API though, perhaps sending JSON to the endpoint instead. In particular, I'd like to change the API to look like: { "public_key": { "type": "ssh-*", "bytes": "base64byteshere==", "comment": "my key!", }, "key_type": "user|host", } to allow Hallow to issue Host Certificates too. Alternatively, we can set this in http X-Hallow-* headers. I like that slightly less. As a stop-gap, we can support both inputs by checking the first byte, since { is not a valid ssh key type, and then drop the old format after we're sure all client binaries out there have been forward-ported. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#66?email_source=notifications&email_token=AAAAGBENES5BDX66MULGYGTRB5XLZA5CNFSM4KR6XDUKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IMBFQ4Q>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBB7XZKJ4Z6UD4VVGWDRB5XLZANCNFSM4KR6XDUA> .

[paultag]

@alex The use-case is so you don't have to rely on TOFU, or if you have an autoscaling cluster where the key changes frequently, the key validation happens by distributing a set of public keys to validate against.

As for what to use for principal, I think I'd likely try to add in a Hallow::Principals tag on a Role, and have hallow call iam:GetRole to fetch tags, and set the principal to the space delimited value of that tag, if set. This could also be used for User certificates, but I don't think I would encourage that, since every user on most aws machines is either ubuntu or ec2-user

[alex]

Interesting, does that work for all (important) cases? It seems like that requires a role-per-EC2 instance. What happens if you've got an ASG?

[paultag]

@alex less per-instance, and more per-fqdn. I have a service that speaks ssh, and I'm going to deploy that fronted with an NLB (likely via fargate), and each instance part of the group will be given a specific role, all of which are handling requests for a specific fqdn.

That means I either have to share the private key material across the entire cluster (meh), ignore keys (double meh) or use signed host keys.

(If you're interested, it's a freetime project and is designed with Hallow in mind)

[alex]

So, if I follow: your use case is for a service that operates using the SSH protocol, not actually conventional SSHing into a server?

[paultag]

@alex correct, yes!

[alex]

Interesting. I'm not sure how I feel, something about it feels scope creepy, but I can't identify why, which suggests it's not a good concern :-)

Anyways, I think allowing posting the data as JSON seems like a reasonable thing, since it gives us an avenue for extensibility. I'm cautiously in favor of just doing content-type detection on the body, instead of a whole new endpoint.

[paultag]

OK, why don't we sleep on this and come to a consensus by like wednesday? I'm also not super wed to this, and I can work around it for my hack.

[alex]

Sure. I think maybe all the individual pieces here are reasonable, even if I'm not sold on the goal :-)

…

On Sun, Feb 9, 2020 at 2:11 PM Paul Tagliamonte ***@***.***> wrote: OK, why don't we sleep on this and come to a consensus by like wednesday? I'm also not super wed to this, and I can work around it for my hack. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#66?email_source=notifications&email_token=AAAAGBD6ITCNNWDHT4FW7KTRCBIOPA5CNFSM4KR6XDUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELGVGGI#issuecomment-583881497>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBAICE7H3BI24DD52SLRCBIOPANCNFSM4KR6XDUA> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[paultag]

Punting until later, once we better understand scope and priorities.