Sending it again. Apparently [email protected] which AFAIK should have been an alias to avoid issues with non-working OpenShift ML doesn't work anymore:
=== This is the mail system at host mx1.redhat.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <[email protected]>: host int-mx-phx2.corp.redhat.com[10.4.122.10] said: 550 5.1.1 <[email protected]>... User unknown (in reply to RCPT TO command) === Re-sending to [email protected] On Fri, 2017-02-24 at 06:33 +0100, Tomas Nozicka wrote: > Hi Luke, > > thanks for your feedback. > > (see inline) > > On Thu, 2017-02-23 at 14:55 -0500, Luke Meyer wrote: > > It's great to see someone tackling this. Thanks. > > > > Definitely should be running with less than cluster-admin > > privileges > > Yes, it doesn't actually need privileges that high, but I was not > aware > of another predefined role suitable for this. Surely an advanced > admin > can define a proper role for it. And actually the controller can run > in > 2 modes: > 1) Cluster level controller > - manages routes across namespaces and needs to watch/write routes > and secrets across the cluster > - in future it could be probably run in default namespace as an > add- > on to OpenShift > - requires system admin (privileges) to install > > 2) multiple namespace controller > - You can actually restrict the controller to several explicit > namespaces [1] > - You can do it as a regular user for all the namespaces you have > permissions to watch/write routes and secrets > - reasoning is that you you run it on cluster like Online where > convincing admins to run it isn't an option (But hopefully this can > make it to Online one day) > > > if it's going to be running in a pod - discussions have always > > counted that as too much security risk. I'm not sure exactly how > > but > > Why is it a security risk to run any controller in a pod? AFAIK even > half of the Kubernetes components can be run in a pod (apiserver, > scheduler, controller-manager). Could you point me to some of those > discussions? > > > you'd probably want to define a role that allows access to exactly > > what's needed. > > Yeah, I should document a way to setup a more restricted role for > running this controller. It just wasn't a priority at this point > because those who care enough can do it on their own. But PRs are > always welcome! > (README actually says: "One way to allow necessary privileges is > shown > bellow, but you might set up more specific policy if you like.") > > > > > Ideally this would be a kube/openshift master controller. Have we > > made any progress on pluggable controllers yet? > > I am not aware of this concept. Would you, or anyone else, mind > pointing me to some docs or design documents? > My understanding was that a controller can be any program that > connects > to OpenShift/Kubernetes API and executes actions to bring the cluster > to a desired state described by resources. > > And actually I believe Clayton wrote an email this week mentioning a > move from embedding Kubernetes to running on top of it - this sounded > to me like running OpenShift components (controllers) in pods and > registering extended APIs but I might have just misunderstood the > meaning. > > Thanks, > Tomas > > [1] - https://github.com/tnozicka/openshift-acme/blob/master/pkg/cmd/ > cm > d.go#L94 > > > > > > > On Mon, Feb 20, 2017 at 12:08 PM, Tomas Nozicka <[email protected] > > m> > > wrote: > > > Hi all, > > > > > > I finally have some news to share. > > > > > > I've got the code working and polished. It now resides in the > > > master > > > branch and there is CI testing the code and pushing images to > > > Docker > > > Hub. > > > > > > For those who knew the previous name the project is now called > > > "openshift-acme". It is an OpenShift/Kubernetes controller > > > written > > > in > > > Go doing certificate management using ACME protocol. (Let's > > > Encrypt > > > is > > > one of the ACME providers.) > > > > > > It aims to be production (scale) ready, but right now it's in > > > pre- > > > alpha > > > stage. That said I would appreciate your feedback early on so > > > please go > > > there [1] and try it out. I will appreciate your feedback and as > > > always > > > PRs are welcome! > > > > > > You can find out more on GitHub: > > > https://github.com/tnozicka/openshift-acme > > > > > > Few caveats at the end: > > > - at this point the controller supports only OpenShift Routes > > > (It > > > is > > > designed with Ingress and Secrets in mind, it just needs a bit of > > > plumbing which I didn't have time to write yet. There is a > > > section > > > of > > > design doc describing it [2]) > > > - it doesn't do dns-01 challenges yet > > > - it's using k8s/client-go with custom serialization for > > > OpenShift > > > Routes but I will get rid of it once OpenShift has their client- > > > go > > > ready > > > - probably some more... > > > > > > Regards, > > > Tomas > > > > > > [1] - https://github.com/tnozicka/openshift-acme#deploy > > > [2] - https://github.com/tnozicka/openshift-acme/blob/master/docs > > > /d > > > esig > > > n/architecture.adoc#supported-objects _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
