... snip ...
> > * Contributor resources in the fedorainfracloud
> > * Once our cloud is upgraded, we can use ipsilon to let users
> > login to the cloud and spin up instances for Fedora related needs.
> > * Outgoing restrictions would be added on port 25 and the like
> > * To start with users would only get 1 external floating ip.
> > * Initial rollout would enable qa and packager groups, need to
> > see if docs and i18n or other groups would have a use for it.
> > * would note that we can terminate any instance for any reason.
> > * Patrick would write some scripting to notify users after some
> > time and terminate if we didn't get an answer back.
> Even with all of these restrictions, I think that the potential for
> abuse exists. I'd like to see these instances (which I think that it's
> a good idea to have) be locked down tighter than Fort Knox :). I think
> that the only thing that they should be able to externally communicate
> with should be the rest of Infrastructure (koji and the like) just
> like anybody on the Internet communicates with those services. They
> should be no more trusted than the computer that I'm writing this on
> right now is, and perhaps even less so (if that's possible and makes
Well, we are opening these to packager and qa to start with. This is
hardly an untrusted group. Additionally it should be easy to blacklist
folks who abuse things. I guess the amount we need to lock things down
depends somewhat on the use cases people come up with.
Note that the cloud instances are totally untrusted by our internal
as far as the other boxes concern, they're just internet.
> > * Fedora CA and cert infrastructure.
> > * Current CA expires in 2018.
> > * Plans being worked on now to back fas3 with freeipa so we could
> > move to kerberos tickets for koji then
> > * Need to figure out what would need to happen to sigul for that.
> > * Wait and see pending freeipa/fas3 integration.
> This sounds reasonable, but what happens if for some reason the
> integration doesn't happen or doesn't happen in a timely manner? I
> don't think that renewing the cert would be a huge deal, because the
> users of the certs generated by that CA are a well-known quantity
> (packagers and releng). The support burden of swapping out the CA cert
> I wouldn't think would be *that* bad. I'm not sure off the top of my
> head, how often do the user certs expire?
It's every 6 months for user certs. Yeah, we could extend the CA expire
time if needed.
The integration code is now live in staging, and is fairly small and
> infrastructure mailing list