|
Re: SSL termination for private domains
Carlo Alberto Ferraris
Mike,
thanks for keeping the ball rolling! For the TLS termination part we are currently using a setup very similar to the one described by Mike. We sit behind a bunch of SLBs that handle termination for us. The main difference is that we're moving out of the "one VIP per cert" model Mike describes to "one SNI VIP for all certs" - a choice we made exactly to keep options open when it comes to automating this process. The biggest pain comes from the fact that the SLB in our organization is handled by a different team and that therefore every cert add/update/delete operation requires a manual operation spanning three teams (application team, our team, SLB team); in the worst cases such operations can take days. We may be different in this from other CF operators, but this situation happens fairly frequently. To put it simply, if CF (gorouter or a different component) had a way to dynamically apply certificates specified by the users (and operators) we would gladly switch away from our current setup. We were also considering (idea stage, nothing really planned yet) using either nginx or a custom-built TLS terminator for this very purpose (the main reason we're considering something custom built is because it's somewhat hard to get session ticket key rotation right with nginx when you have multiple servers) - but if something functionally equivalent were to appear upstream we would definitely prefer it. I hope everything makes sense, if not I'll gladly answer any question you may have. Thanks for looking into this! Carlo |
|
|
|
Re: Announcing Volume Services for Cloud Foundry
Paul Bakare
Thank you very much.
toggle quoted message
Show quoted text
So much awesomeness. On Wed, Sep 21, 2016 at 12:00 AM, Shawn Nielsen <sknielse(a)gmail.com> wrote:
Thanks to all who helped contribute and make this happen! This is |
|
|
|
Re: SSL termination for private domains
Mike Youngstrom <youngm@...>
An extension point would be more useful than something that only worked on
toggle quoted message
Show quoted text
the gorouters. Another thing that mitigates our need for this feature is that most all of our organization's applications (CF deployed or not) use one of 2 main wildcard domains. Use of domains outside these 2 are rare. We built a custom iteration with our DNS solution and CF that looks for new CF routes using one of those 2 domains and automatically add a dns entry (if not already taken) pointing to shared VIPs on our FLB that have a matching wildcard cert already configured. That allows us to add those 2 domains as CF shared domains that anyone can create routes for. Even though the domains are not dedicated to CF. I suppose that would be another reason why this isn't currently a major pain point for my users. Mike On Tue, Sep 20, 2016 at 3:54 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
Mike, |
|
|
|
Re: Announcing Volume Services for Cloud Foundry
Shawn Nielsen
Thanks to all who helped contribute and make this happen! This is
toggle quoted message
Show quoted text
fantastic news. On Tue, Sep 20, 2016 at 3:56 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:
This is great! Something many of my customers have been wanting for a |
|
|
|
Re: Announcing Volume Services for Cloud Foundry
Mike Youngstrom <youngm@...>
This is great! Something many of my customers have been wanting for a long
toggle quoted message
Show quoted text
time. Now to figure out how to integrate it with our NetApp NFS. Mike On Tue, Sep 20, 2016 at 3:31 PM, Ted Young <tyoung(a)pivotal.io> wrote:
As of cf-242 |
|
|
|
Re: SSL termination for private domains
Shannon Coen
Mike,
toggle quoted message
Show quoted text
What if the way the gorouters were configured with user-provided certs was a point of extension that could also be used to configure your FLB? How often do you have to manage certs on your LB? Is this of low value? Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Tue, Sep 20, 2016 at 12:43 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:
For us we handle all ssl termination in our FLB (Frontend Load Balancer). |
|
|
|
Re: Announcing Volume Services for Cloud Foundry
Chip Childers <cchilders@...>
+1 ... this is awesome to see released!
On Tue, Sep 20, 2016 at 5:33 PM Amit Gupta <agupta(a)pivotal.io> wrote: Sweet!!!Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815 |
|
|
|
Re: Announcing Volume Services for Cloud Foundry
Amit Kumar Gupta
Sweet!!!
toggle quoted message
Show quoted text
On Tue, Sep 20, 2016 at 2:31 PM, Ted Young <tyoung(a)pivotal.io> wrote:
As of cf-242 |
|
|
|
Announcing Volume Services for Cloud Foundry
Ted Young
As of cf-242
<http://bosh.io/releases/github.com/cloudfoundry/cf-release?version=242> and Service Broker API v2.10, Cloud Foundry now ships with support for *Volume Services*: filesystem-based data services. The v2.10 API is a release candidate, and will be considered GA unless a bug in the implementation is fond. An experimental version of the API was added in v2.9. Until recently, the only data services that have been allowed are ones with network-based interfaces, such as a SQL database. With Volume Services, brokers can now attach data services which have a filesystem-based interface. Currently, we have platform support for Shared Volumes. Shared Volumes are distributed filesystems, such as NFS-based systems, which allow all instances of an application to share the same mounted volume simultaneously and access it concurrently. This feature adds two new concepts to CF: *Volume Mounts* for Service Brokers and *Volume Drivers* for Diego Cells. Details can be found in the links below. *Documentation:* https://bit.ly/cf-volume-services *CF Summit Talk:* https://www.youtube.com/watch?v=ajNoPi1uMjQ If you're going to CF Summit Europe, be sure to check out Julian's talk detailing the types of Shared Volume Services available, and their usecases. If you're interested in rolling out a volume service, please be in touch. You can ask questions here, on the OSS #persi <https://cloudfoundry.slack.com/archives/persi> slack channel, or email me directly at tyoung(a)pivotal.io. Cheers, Ted Young Persistence Project Lead, Pivotal |
|
|
|
Re: Do we connect to the CF when we setup using pcfdev
Daniel Jones
Hi Praveen,
It doesn't matter who looks up anything.local.pcfdev.io. The answer is always the same address, which is always local: 192.168.11.11. It's a bit like if the DNS record always returned 127.0.0.1 (localhost): http://networkengineering.stackexchange.com/a/5830 Regards, Daniel Jones - CTO +44 (0)79 8000 9153 @DanielJonesEB <https://twitter.com/DanielJonesEB> *EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry Specialists On Tue, Sep 20, 2016 at 8:35 PM, Praveen sadineni <sadinenip(a)gmail.com> wrote: Hello Daniel, |
|
|
|
Re: SSL termination for private domains
Mike Youngstrom <youngm@...>
For us we handle all ssl termination in our FLB (Frontend Load Balancer).
toggle quoted message
Show quoted text
If a customer adds a custom domain then my team needs to add a vip and associated cert for that domain. This is something I don't think CF could do for us because we are using our FLB. So, FWIW this isn't a feature we would use since we use or FLB to manage this instead. Mike On Mon, Sep 19, 2016 at 11:25 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
Some time ago I sketched out an epic to add support for multiple certs to |
|
|
|
Repository deprecation notice: github.com/cloudfoundry/buildpack-releases
Stephen Levine
Hi All,
The CF Buildpacks team recently migrated the BOSH releases for the system buildpacks from subdirectories of the github.com/cloudfoundry/buildpack-releases repository to individual repositories for each release. For example, the Ruby buildpack BOSH release is now available at: https://github.com/cloudfoundry/ruby-buildpack-release The buildpack-release repository has already been moved to the cloudfoundry-attic Github org. Starting on October 20, 2016, the repository will no longer be updated with the latest buildpack releases. Thanks, Stephen Levine CF Buildpacks PM |
|
|
|
Re: Do we connect to the CF when we setup using pcfdev
Praveen sadineni
Hello Daniel,
if that is the case and if it is going to public DNS how it is resolving to which VM's it has to be , for example I have used the same IP and other 2 members also used the same IP and if it is connecting to public which IP will be resolved to serve. |
|
|
|
Re: Do we connect to the CF when we setup using pcfdev
Stephen Levine
Hi Daniel,
I've prioritized a story to investigate your StackExchange issue. We'll update the documentation with any findings. Praveen, are you also running OS X? Can you open a PCF Dev Github issue describing how the work offline doc fails for you? Thanks, Stephen On Tue, Sep 20, 2016 at 3:12 PM, Daniel Jones < daniel.jones(a)engineerbetter.com> wrote: Hi Praveen, |
|
|
|
Re: Do we connect to the CF when we setup using pcfdev
Daniel Jones
Hi Praveen,
The name records for *.local.pcfdev.io always refer back to the same (local) IP: 192.168.11.11. So you make a call out to the public internet to resolve the DNS record, but then requests are only send to the VM running locally. I've had issues trying to get DNSMasq to work as documented on my Mac, and I haven't had time to get to the bottom of it yet: http://apple.stackexchange.com/questions/251678/dns-resolution-fails-for-ping-and-curl-but-not-dig Regards, Daniel Jones - CTO +44 (0)79 8000 9153 @DanielJonesEB <https://twitter.com/DanielJonesEB> *EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry Specialists On Tue, Sep 20, 2016 at 7:33 PM, Praveen sadineni <sadinenip(a)gmail.com> wrote: How is it resolving the DNS when we have PCF dev locally? |
|
|
|
Re: Do we connect to the CF when we setup using pcfdev
Praveen sadineni
How is it resolving the DNS when we have PCF dev locally?
When we connect to https://local.pcfdev.io it basically redirects to console.local.pcfdev.io and again redirecting to uaa.local.pcfdev.io , which means it is connecting some how some where , where does this user authentication happen. We have tried the setup to make use locally and it is not sucessful.(http://docs.pivotal.io/pcf-dev/work-offline.html). |
|
|
|
Re: Do we connect to the CF when we setup using pcfdev
Stephen Levine
Hi Praveen,
PCF Dev does not connect to a separate PCF or CF installation. PCF Dev can be administered using the cf CLI (by following the instructions at boot) or using Apps Manager (by opening a browser to https://local.pcfdev.io). PCF Dev requires an internet connection to resolve *.local.pcfdev.io addresses using public DNS. If you would like to run PCF Dev without an internet connection, see here: http://docs.pivotal.io/pcf-dev/work-offline.html In the future, questions about PCF Dev can be asked at our Github issue tracker: http://docs.pivotal.io/pcf-dev/work-offline.html Thanks, Stephen PCF Dev PM On Tue, Sep 20, 2016 at 11:41 AM, Praveen sadineni <sadinenip(a)gmail.com> wrote: Hello , |
|
|
|
Do we connect to the CF when we setup using pcfdev
Praveen sadineni
Hello ,
I have a PCFdev setup and when evr we deploy an application or do any administration of PCFdev where do we connect , Is it that all locally we do this or do we connect to PCF , Secondly if we are connecting to PCF why are we connecting and if we are not connecting to PCF why do I need to have internet to push the applications, when I disable the internet we get error. or we cannot even see the console. |
|
|
|
Re: Announcement: default etcd cluster to TLS in cf-release spiff templates
Grifalconi, Michael <michael.grifalconi@...>
Hello all,
It’s been a couple of days that we are struggling on the update of CF v240 to v241 together with the TLS upgrade for etcd. We are following the guide provided but we always get random deployment failures during the step about adding the etcd TLS node and the etcd http proxy job. Our deployment failed because of hm9000, loggregator_trafficcontroller and doppler. Not all together, but one after the others: first if failed because of hm9000, hit deploy again and at the 3rd time it worked; same for loggregator. For doppler it didn’t help to try multiple times (error was ‘panic: sync cluster failed’). We solved this by restarting both the single etcd (with TLS) and the proxy. We deployed v240 from scratch and did the upgrade several times and we never had a ‘clean’ deployment, we always got a lot of issues that has been fixed by just a second (or third) try with no changes or by stopping all etcd vms, deleting the persistent storage and restarting them. This is a no-go for productive deployments. Do you have any ideas on this topic? Are we doing something wrong? Thanks a lot Best, Michael From: Amit Gupta <agupta(a)pivotal.io> Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: Thursday 15 September 2016 at 03:34 To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Subject: [cf-dev] Announcement: default etcd cluster to TLS in cf-release spiff templates Hi all, I'd like to change the cf-release manifest generation templates to default to running etcd in secure TLS mode. It currently supports both TLS and non-TLS modes of operation. The etcd job will support both modes of operation for the near future, but I'd like to make the manifest scripts only support TLS, meaning anyone using those templates will either need to switch to TLS mode or do their own post-processing of the manifest to disable TLS. Detailed instructions for upgrading a non-TLS cluster to a TLS cluster with zero downtime are here: https://docs.google.com/document/d/1ZzWzp3H6H3t1ikk6Fl-8x1LX2a_0dHPJ5MMLEwY0inI/edit. Note that this should allow for zero app and logging downtime, but minimal downtime for certain features such as binding a syslog-drain-url service. Please let me know if you have any feedback about this forthcoming change. Best, Amit |
|
|
|
Re: SSL termination for private domains
Shannon Coen
Some time ago I sketched out an epic to add support for multiple certs to
gorouter, configured via BOSH manifest property, but these stories have languished in the icebox while we've addressed more urgent work. I would like to hear from the community whether an operator managed feature would be of value, as it would be relatively cheap. I have also heard requests for user self-service management of certs for private domains, as Carlo described. This would be a much more complex feature to deliver, but I can certainly see the value. Tell me about the pain of managing TLS certificates. How are you dealing with this today? Which of these approaches would be more helpful in enabling your developers? Which of these features would you be more disappointed to hear would not be delivered? Thank you! Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Mon, Sep 19, 2016 at 6:11 PM, Carlo Alberto Ferraris < carlo.ferraris(a)rakuten.com> wrote: I have a question about the SSL termination epic[1], whose goal IIUC is to |
|
|