|
Re: SSL termination for private domains
Our current policy to our users is SNI by default, i.e. unless they explicitly require non-SNI TLS termination they get SNI termination. We went with this because browser support seems good[1] and because there are "easy" (albeit manual) workarounds (request a non-SNI VIP, use a CDN). Granted, even with SNI TLS termination in gorouter we should still be able to perform TLS termination somewhere else for the few cases in which no SNI is really a requirement - but for this it's enough to not change the HTTP listener behavior. [1]: http://caniuse.com/#feat=sni
|
|
|
Re: SSL termination for private domains
Thank you all for your responses.
A follow up question: for the gorouter to host certs for multiple domains,
it seems only natural that it would do this via SNI. Is client support for
SNI ubiquitous among apps running on your CF deployments? Would it be
reasonable to require client SNI support for TLS termination at gorouter?
Thanks again.
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
toggle quoted message
Show quoted text
On Wed, Sep 21, 2016 at 5:52 AM, James Leavers <james(a)cloudhelix.io> wrote: It sounds like we are in a similar situation to Carlo, i.e.
- We have an external pair of LBs
- These are used for SSL termination
- We upload SSL certificates to the LBs for various domains, which
point to the same VIP
If something became available that would easily allow app developers /
users to upload their own certificates, I too would happily move SSL
termination from the LBs to gorouter, as it would mean one less automation
workflow for us :-)
On 21 September 2016 at 02:04:48, Shannon Coen (scoen(a)pivotal.io) wrote:
Carlo, Mike, others,
Do you store certs in the LB config itself, or federate/offload TLS
termination to some secure store? I'm thinking about storing user-provided
certs in the Routing API and offering them to routers/LBs from there. Would
we instead have to send the certs to some other proprietary system from
where the router/LB would have to pull from?
I've heard a few requests for integrating with systems that store the
certs so that the routers don't have access to the keys.
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Tue, Sep 20, 2016 at 5:44 PM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:
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: SSL termination for private domains
On Tue, Sep 20, 2016 at 10:00 PM, Carlo Alberto Ferraris < carlo.ferraris(a)rakuten.com> wrote: While we're talking about TLS, but this is only partially related, it
would be awesome if we were to implement (or some hooks were provided to be
able to complete) either the http or tls ACME challenges. That would be the
ultimate dream. :D
Wasn't familiar with ACME until I just googled it. Do you mean some mechanism for automated generation of certs?
|
|
|
Re: Do we connect to the CF when we setup using pcfdev
Hello Stephen,
I am using Windows 10 and I have opened a issue in Github.
|
|
|
Re: SSL termination for private domains
It sounds like we are in a similar situation to Carlo, i.e.
- We have an external pair of LBs
- These are used for SSL termination
- We upload SSL certificates to the LBs for various domains, which point
to the same VIP
If something became available that would easily allow app developers /
users to upload their own certificates, I too would happily move SSL
termination from the LBs to gorouter, as it would mean one less automation
workflow for us :-)
toggle quoted message
Show quoted text
On 21 September 2016 at 02:04:48, Shannon Coen (scoen(a)pivotal.io) wrote: Carlo, Mike, others, Do you store certs in the LB config itself, or federate/offload TLS termination to some secure store? I'm thinking about storing user-provided certs in the Routing API and offering them to routers/LBs from there. Would we instead have to send the certs to some other proprietary system from where the router/LB would have to pull from? I've heard a few requests for integrating with systems that store the certs so that the routers don't have access to the keys. Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Tue, Sep 20, 2016 at 5:44 PM, Carlo Alberto Ferraris < carlo.ferraris(a)rakuten.com> wrote: 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: SSL termination for private domains
+1 to user provided certs for private domains. Today, we use multiple vips with diff certs or our main vip with a cert that has multiple SANs.
Our goal is for cf operators to really be out of the way for app specific concerns and we view the certs and private domains (vanity dns names) as an application concern.
Having this ability provides immense value to us.
Regards,
Anthony
toggle quoted message
Show quoted text
On Sep 20, 2016, at 8:03 PM, Shannon Coen <scoen(a)pivotal.io> wrote: Carlo, Mike, others, Do you store certs in the LB config itself, or federate/offload TLS termination to some secure store? I'm thinking about storing user-provided certs in the Routing API and offering them to routers/LBs from there. Would we instead have to send the certs to some other proprietary system from where the router/LB would have to pull from? I've heard a few requests for integrating with systems that store the certs so that the routers don't have access to the keys. Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Tue, Sep 20, 2016 at 5:44 PM, Carlo Alberto Ferraris <carlo.ferraris(a)rakuten.com> wrote:
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
This is ridiculously cool - nice work Persils!
toggle quoted message
Show quoted text
On Wed, 21 Sep 2016 at 02:50, Shannon Coen <scoen(a)pivotal.io> wrote: Persistence!
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Tue, Sep 20, 2016 at 4:28 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:
Thank you very much.
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
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
long 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
<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
--
Odeyemi 'Kayode O.
http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde
|
|
|
Re: SSL termination for private domains
While we're talking about TLS, but this is only partially related, it would be awesome if we were to implement (or some hooks were provided to be able to complete) either the http or tls ACME challenges. That would be the ultimate dream. :D
|
|
|
Re: SSL termination for private domains
We don't have the requirement to use an external secure store, but for that custom terminator component we were thinking to use an external secure store (Vault or something along those lines) to make sure that the the private keys and session ticket keys never hit persistent storage.
|
|
|
Re: SSL termination for private domains
Carlo, Mike, others, Do you store certs in the LB config itself, or federate/offload TLS termination to some secure store? I'm thinking about storing user-provided certs in the Routing API and offering them to routers/LBs from there. Would we instead have to send the certs to some other proprietary system from where the router/LB would have to pull from? I've heard a few requests for integrating with systems that store the certs so that the routers don't have access to the keys. Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Tue, Sep 20, 2016 at 5:44 PM, Carlo Alberto Ferraris < carlo.ferraris(a)rakuten.com> wrote: 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
Persistence!
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
toggle quoted message
Show quoted text
On Tue, Sep 20, 2016 at 4:28 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote: Thank you very much.
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
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
long 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
<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
--
Odeyemi 'Kayode O.
http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde
|
|
|
Re: SSL termination for private domains
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
Thank you very much.
So much awesomeness.
toggle quoted message
Show quoted text
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
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
long 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
<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: SSL termination for private domains
Mike Youngstrom <youngm@...>
An extension point would be more useful than something that only worked on
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
toggle quoted message
Show quoted text
On Tue, Sep 20, 2016 at 3:54 PM, Shannon Coen <scoen(a)pivotal.io> wrote: Mike,
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). 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 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 provide the ability for operators to have multiple TLS certificates: it
seems only shared domains are being considered (because the stories talk
about *operators* setting up multiple certs); are there no plans for
private domains? Put otherwise: are there plans for allowing *users* to
provide the cert for a domain they registered in their org?
[1] https://www.pivotaltracker.com/epic/show/2135866
(I originally posted the question on slack but got no reply, so
crossposting here)
|
|
|
Re: Announcing Volume Services for Cloud Foundry
Thanks to all who helped contribute and make this happen! This is
fantastic news.
toggle quoted message
Show quoted text
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
long 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
<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: Announcing Volume Services for Cloud Foundry
Mike Youngstrom <youngm@...>
This is great! Something many of my customers have been wanting for a long
time. Now to figure out how to integrate it with our NetApp NFS.
Mike
toggle quoted message
Show quoted text
On Tue, Sep 20, 2016 at 3:31 PM, Ted Young <tyoung(a)pivotal.io> wrote: 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: SSL termination for private domains
Mike,
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.
toggle quoted message
Show quoted text
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).
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
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 provide the ability for operators to have multiple TLS certificates: it
seems only shared domains are being considered (because the stories talk
about *operators* setting up multiple certs); are there no plans for
private domains? Put otherwise: are there plans for allowing *users* to
provide the cert for a domain they registered in their org?
[1] https://www.pivotaltracker.com/epic/show/2135866
(I originally posted the question on slack but got no reply, so
crossposting here)
|
|
|
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!!!
On Tue, Sep 20, 2016 at 2:31 PM, Ted Young <tyoung(a)pivotal.io> wrote:
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
-- Chip Childers VP Technology, Cloud Foundry Foundation 1.267.250.0815
|
|
|
Re: Announcing Volume Services for Cloud Foundry
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
<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
|
|
|
Announcing Volume Services for Cloud Foundry
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=ajNoPi1uMjQIf 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
|
|
|
