Hey. How ready is it to use on production? Is there any plans to change interfaces/mechanisms in the near future?
Thanks, great job! ;) Em 5 de set de 2017 2:23 PM, "Tim Dudgeon" <[email protected]> escreveu: > Tomas > > Thanks, that helped. > > The problem was that it wasn't clear that you needed to install into a new > project, and then update the > > oc adm policy add-cluster-role-to-user acme-controller > system:serviceaccount:acme:default > > command and replace acme with the name of the project. Once done it > installs fine and issues certificates as described. > > Thanks > Tim > > > On 05/09/2017 17:38, Tomas Nozicka wrote: > >> Hi Tim, >> >> (see inline...) >> >> On Tue, 2017-09-05 at 17:12 +0100, Tim Dudgeon wrote: >> >>> Thanks. >>> >>> I'm having problems getting this running. >>> When I deploy the deploymentconfig the pod fails to start and the >>> logs >>> contain these errors: >>> >>> 2017-09-05T16:03:11.764025351Z ERROR cmd.go:138 Unable to >>>> bootstrap >>>> certificate database: 'User >>>> >>> and >>> >>>> 2017-09-05T16:03:11.766213869Z ERROR cmd.go:173 Couln't >>>> initialize >>>> RouteController: 'RouteController could not find its own service: >>>> 'User "system:serviceaccount:acme-controller:default" cannot get >>>> services in project "acme-controller"'' >>>> >>> misconfigured SA is system:serviceaccount:acme-controller:default >> - notably the namespace is **acme-controller** >> >> I already deployed the clusterrole and executed >>> >>> oc adm policy add-cluster-role-to-user acme-controller >>>> system:serviceaccount:acme:default >>>> >>> Even tried as suggested: >>> >>> oc adm policy add-cluster-role-to-user cluster-admin >>>> system:serviceaccount:acme:default >>>> >>> You are modifying SA in namespace **acme** not **acme-controller** >> >> I tried this in the default project and in a new acme-controller >>> project. >>> >>> Could you help describe steps to get this running in a new openshift >>> environment? >>> >> Try looking at the exact steps our CI is using to create it from >> scratch but it should work as described in our docs. >> >> https://github.com/tnozicka/openshift-acme/blob/master/.travis.yml#L6 >> 7-L73 >> >> Thanks >>> Tim >>> >>> >>> >>> On 04/09/2017 09:44, Tomas Nozicka wrote: >>> >>>> Hi Tim, >>>> >>>> On Mon, 2017-09-04 at 09:16 +0100, Tim Dudgeon wrote: >>>> >>>>> Tomas >>>>> >>>>> Thanks for that. Looks very interesting. >>>>> >>>>> I've looked it over and not totally sure how to use this. >>>>> >>>>> Am I right that if this controller is deployed and running >>>>> correctly >>>>> then all you need to do for any routes is add the >>>>> 'kubernetes.io/tls-acme: "true"' annotation to your route and >>>>> the >>>>> controller will handle creating the initial certificate and >>>>> renewing >>>>> it >>>>> as needed? >>>>> >>>> Correct. >>>> >>>> And in doing so it will generate/renew certificate for the >>>>> hostname, >>>>> add/update it as a secret, and update the route definition to use >>>>> that >>>>> certificate? >>>>> >>>> For Routes it will generate a secret with that certificate and also >>>> inline it into the Route as it doesn't support referencing it. >>>> (Ingresses do, but the project doesn't support those yet.) The >>>> secret >>>> can be useful for checking or mounting it into pods directly if you >>>> don't want to terminate your TLS in the router but in pods. >>>> >>>> And that this will only apply to external routes. Some mechanism, >>>>> such >>>>> as the Ansible playbook, will still be required to maintain the >>>>> certificates that are used internally by the Openshift >>>>> infrastructure? >>>>> >>>> I have some thoughts on this but no code :/ >>>> >>>> As I said at this point you need to bootstrap the infra using your >>>> own >>>> CA/self-signed cert and then you can expose the OpenShift API + web >>>> console using a Route. This should work fine even for 'oc' client >>>> unless the Router is down and you need to fix it. For that rare >>>> case, >>>> when only the admin will need to log in to fix the router he can >>>> use >>>> the internal cert or ssh into the cluster directly. >>>> >>>> So this hack should cover all the use cases for users except this >>>> special case for an admin. >>>> >>>> Thanks >>>>> Tim >>>>> >>>>> On 25/08/2017 17:09, Tomas Nozicka wrote: >>>>> >>>>>> Hi Tim, >>>>>> >>>>>> there is a controller to take care about generating and >>>>>> renewing >>>>>> Let's >>>>>> Encrypt certificates for you. >>>>>> >>>>>> https://github.com/tnozicka/openshift-acme >>>>>> >>>>>> That said it won't generate it for masters but you can expose >>>>>> master >>>>>> API using Route and certificate for that Route would be fully >>>>>> managed >>>>>> by openshift-acme. >>>>>> >>>>>> Further integrations might be possible in future but this is >>>>>> how >>>>>> you >>>>>> can get it done now. >>>>>> >>>>>> Regards, >>>>>> Tomas >>>>>> >>>>>> >>>>>> On Fri, 2017-08-25 at 16:27 +0100, Tim Dudgeon wrote: >>>>>> >>>>>>> Does anyone have any experience on how best to use Let' >>>>>>> Encrypt >>>>>>> certificates for an OpenShift Origin cluster? >>>>>>> >>>>>>> In once sense this is simple. The Ansible installer can be >>>>>>> specified >>>>>>> to >>>>>>> use this custom certificate and key to sign all the >>>>>>> certificates >>>>>>> it >>>>>>> generates, and doing so ensures you don't get the dreaded >>>>>>> "This >>>>>>> site >>>>>>> is >>>>>>> insecure" messages from your browser. And there is a playbook >>>>>>> for >>>>>>> updating certificates (which is essential as Let' Encrypt >>>>>>> certificates >>>>>>> are short lived) so this must be automated. >>>>>>> >>>>>>> But how best to set this up and automate the certificate >>>>>>> generation >>>>>>> and >>>>>>> renewal? >>>>>>> >>>>>>> Let's assume Ansible is being run from a separate machine >>>>>>> that is >>>>>>> not >>>>>>> part of the cluster and needs to deploy those custom >>>>>>> certificates >>>>>>> to >>>>>>> the >>>>>>> master(s). The certificate needs to be present on the ansible >>>>>>> machine >>>>>>> but needs to apply to the master(s) (or load balancer?). So >>>>>>> you >>>>>>> can't >>>>>>> just generate the certificate on the ansible machine (e.g. >>>>>>> using >>>>>>> --standalone option for certbot) as it would not be for the >>>>>>> right >>>>>>> machine. >>>>>>> >>>>>>> Similarly it doesn't seem right to request and update the >>>>>>> certificates >>>>>>> on the master (which master in the case of multiple >>>>>>> masters?), >>>>>>> and >>>>>>> those >>>>>>> certificates need to be present on the ansible machine. >>>>>>> >>>>>>> Seems like the answer might be to run a process on the >>>>>>> ansible >>>>>>> machine >>>>>>> that requests the certificates using the webroot plugin and >>>>>>> in >>>>>>> doing >>>>>>> so >>>>>>> places the magical key that is used to verify ownership of >>>>>>> the >>>>>>> domain >>>>>>> under the https://your.site.com/.well-known/acme-challenge >>>>>>> location? >>>>>>> But >>>>>>> how to go about doing this? Ports 80 and 443 seem to be in >>>>>>> use on >>>>>>> the >>>>>>> cluster, but not serving up any particular content. How to >>>>>>> place >>>>>>> the >>>>>>> content there? >>>>>>> >>>>>>> I'm hoping others have already needed to handle this problem >>>>>>> and >>>>>>> can >>>>>>> point to some best practice. >>>>>>> >>>>>>> Thanks >>>>>>> Tim >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> users mailing list >>>>>>> [email protected] >>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>>>>> >>>>>> >>> > _______________________________________________ > users mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/users >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
