On Fri, 25 Nov 2016 03:19:49 +0100
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Peter Robinson wrote:
> Well the koji web interface itself doesn't use authentication
> anymore, from a fedpkg PoV there's a lot of complexity with http(s)
> because it could be proxied or NATed (worst is CG-NAT) so the same
> connection from the same laptop might not even come via the same
> IP. Basically what you're describing is exactly what kerberos
> solves, tokens to authenticate various different connections.
My point is, just use SSH instead of HTTP(S) as the transport. You
could even tunnel HTTP over an SSH tunnel after you let SSH
authenticate the other end, if you really need an HTTP API. (Not much
point in using HTTPS over the already encrypted SSH.)
Do you know of any applications at all that use this?
Is there any python code available to setup such authentication?
Kerberos is used all over the place by lots and lots of groups and has
had many years of auditing and actually you know, exists.
> A lot of companies and data security standards explicitly
> ssh keys because of the fact it's client side pass phrases with no
> way to enforce a policy so there's no way to tell even if the key
> has a passphrase.
And that is what I like about SSH. :-) I decide the level of security
I actually need for my key, not somebody else.
Which is fine up until the point someone compromises your machines and
uses your access to mess up everyone else.
And we already trust SSH authentication for access to dist-git, so I
don't see why it would not be good enough for Koji as well.
Because it would require a bunch of coding and then we would be a
special little snowflake.
> Personally I'd like to see eventually the move to kerberos
> replace ssh- keys as it's easier to enforce a minimum policy and
Kinit just takes a password, automating it to pick the password from
any password store or even a plaintext file and then run
automatically on startup and automatically renew expired tickets is
not that hard. It will just be a minor annoyance until one of us
writes the automation tool, and do nothing to enforce any kind of
policy on us.
No need to invent all this again, you can just use a keytab.
The infrastructure really needs to work for us, not against us.
I'm happy to work with anyone to improve things. That said, we don't
have a bunch of developers sitting around waiting to implement people's
ideas, so sometimes we have to say "sorry, no" or "sorry, we can't do
that now, but happy to look at it again later".
I think kerberos is a very good improvement over the current setup.
I hope (most)everyone else does too.