Got it, so what I said before hold. We view access control as a must and
partitioned routing table a nice to have.

Thanks,
Mike

On Tue, Jan 24, 2017 at 6:36 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi Mike,

Thank you for the feedback.

Without access control for domains, a developer could map route
foo.example.com (for which the LB will route requests only to the router
group for IS-1) to an app in a space associated with IS-2.

If the routing table is not partitioned, both router groups will have the
route in their routing tables. If the LB is correctly configured, it will
route requests for foo.example.com only to the router group for IS-1.
The routers will attempt to route the request. Assuming the firewalls are
configured correctly, the routers will return a 502.

If the routing table is partitioned, only the router group for IS-2 will
have the route in its routing table. If the LB is correctly configured, it
will route requests for foo.example.com only to the router group for
IS-1. The routers will reject the request immediately, returning a 404.

Either way, the developer is set up for failure.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jan 24, 2017 at 9:05 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Question, Just want to make sure I'm following you. In your Access
Control example you mention that without access control a developer would
be able to create a route to foo.example.com in a space associated with
IS-2, but, that "route will fail". Is this example assuming that the
"Partitioning the Routing Table" feature was implemented, a properly
configured firewalls, or would the route fail for some other reason?

I think for our use cases we only require Access Control. We are
capable of configuring our firewalls and such correctly. :) Partitioned
routing tables would be nice too but I think a lower priority.

Mike

On Mon, Jan 23, 2017 at 6:24 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation
segments for your use cases, we'd like to know whether you would be
inclined to use dedicated routing tiers for isolation groups in production
without the proposed enhancements below, or whether you would require
either/both of the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an
isolated pool of Diego Cells. On its own, this design will rely on a shared
routing tier with access to all isolation segments. This requires an
operator to carefully configure their load balancer and firewall rules to
prevent an attacker using a spoofed Host header to reach an application
that shouldn't be publicly routable.

An operator can currently deploy dedicated deployments of routers for
an isolation segment but the routing table will be shared among them.
Should a misconfigured load balancer forward a request to routers for an
app on another isolation segment, the routers will attempt to route the
request. If the firewall is correctly configured, the router will return a
502. If the firewall is misconfigured, a private app may be publicly
accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation
segment will only route requests for apps in an associated isolation
segment; if a load balancer were misconfigured, and a request for an app in
another isolation segment were forwarded to the routers, a 404 would be
returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A
space is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.
foo.example.com at routers for isolation segment IS-1 and *.
bar.example.com at routers for isolation segment IS-2, there's nothing
preventing an app developer from creating a route from domain
foo.example.com in a space associated with IS-2. Requests to the route
will fail and the developer would not know why. To prevent this, we'll
enable API clients to filter domains by targeted space, so that a developer
only sees domains from which they can create working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements
for routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Hi,

As discussed today, I will be happy to help you run the inception.

If anyone else (with more experience) was interested in helping, please
ping me and Hristo.

See you all (virtually) online on the 31st.

Best,

Max

On Mon, Nov 28, 2016 at 1:29 PM, Michael Maximilien <mmaximilien(a)gmail.com

wrote:

Hi, all,

Thanks to SAP and Hristo for moving this forward.

Since I don't see any questions nor comments on this proposal, other than
mine. As such, I propose to include this into the CF-Extensions PMC.

Next step is to do an inception and start the project.

Hristo, happy to help you. Please let's connect offline or during
CF-Abacus weekly meetings von Friday. You can then announce details here
afterwards.

Welcome. Best,

Max

On Wed, Nov 16, 2016 at 3:51 PM, Michael Maximilien <
mmaximilien(a)gmail.com> wrote:

Thank you Hirsto and SAP for submitting this proposal. A nice extension
for CF.

Made some minor editorial changes but overall proposal looks great.
Looking forward to see feedback (if any) from community.

Best,

Max

On Tue, Nov 15, 2016 at 8:03 AM, Iliev, Hristo <hristo.iliev(a)sap.com>
wrote:

Hello,

I would like to propose to the Extensions PMC a new incubation project
around Abacus.

Project name: Abacus Service Broker
Project proposal: https://docs.google.com/docume
nt/d/1zGYi0jGRX9kodn8WR8OHn6CSjo3BTorfuza121aIeuU/edit?usp=sharing
Proposed Project Lead: Hristo Iliev (SAP)
Proposed Scope: See the "Goals" and "Non-goals" sections in the
proposal
Development Operating Model: Distributed Committer Model
Technical Approach: Refer to "Programming language" and "Deliverables"
in the proposal
Initial team committed: 3 engineers from SAP

I look forward to any questions or comments.

Regards,
Hristo Iliev, SAP

--
max
http://maximilien.org
http://blog.maximilien.com

--
max
http://maximilien.org
http://blog.maximilien.com

--
max
http://maximilien.org
http://blog.maximilien.com

Hi Mike,

Thank you for the feedback.

Without access control for domains, a developer could map route
foo.example.com (for which the LB will route requests only to the router
group for IS-1) to an app in a space associated with IS-2.

If the routing table is not partitioned, both router groups will have the
route in their routing tables. If the LB is correctly configured, it will
route requests for foo.example.com only to the router group for IS-1. The
routers will attempt to route the request. Assuming the firewalls are
configured correctly, the routers will return a 502.

If the routing table is partitioned, only the router group for IS-2 will
have the route in its routing table. If the LB is correctly configured, it
will route requests for foo.example.com only to the router group for
IS-1. The routers will reject the request immediately, returning a 404.

Either way, the developer is set up for failure.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jan 24, 2017 at 9:05 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Question, Just want to make sure I'm following you. In your Access
Control example you mention that without access control a developer would
be able to create a route to foo.example.com in a space associated with
IS-2, but, that "route will fail". Is this example assuming that the
"Partitioning the Routing Table" feature was implemented, a properly
configured firewalls, or would the route fail for some other reason?

I think for our use cases we only require Access Control. We are capable
of configuring our firewalls and such correctly. :) Partitioned routing
tables would be nice too but I think a lower priority.

Mike

On Mon, Jan 23, 2017 at 6:24 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation
segments for your use cases, we'd like to know whether you would be
inclined to use dedicated routing tiers for isolation groups in production
without the proposed enhancements below, or whether you would require
either/both of the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an
isolated pool of Diego Cells. On its own, this design will rely on a shared
routing tier with access to all isolation segments. This requires an
operator to carefully configure their load balancer and firewall rules to
prevent an attacker using a spoofed Host header to reach an application
that shouldn't be publicly routable.

An operator can currently deploy dedicated deployments of routers for an
isolation segment but the routing table will be shared among them. Should a
misconfigured load balancer forward a request to routers for an app on
another isolation segment, the routers will attempt to route the request.
If the firewall is correctly configured, the router will return a 502. If
the firewall is misconfigured, a private app may be publicly accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation
segment will only route requests for apps in an associated isolation
segment; if a load balancer were misconfigured, and a request for an app in
another isolation segment were forwarded to the routers, a 404 would be
returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A
space is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.
foo.example.com at routers for isolation segment IS-1 and *.
bar.example.com at routers for isolation segment IS-2, there's nothing
preventing an app developer from creating a route from domain
foo.example.com in a space associated with IS-2. Requests to the route
will fail and the developer would not know why. To prevent this, we'll
enable API clients to filter domains by targeted space, so that a developer
only sees domains from which they can create working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements for
routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Question, Just want to make sure I'm following you. In your Access Control
example you mention that without access control a developer would be able
to create a route to foo.example.com in a space associated with IS-2,
but, that "route will fail". Is this example assuming that the
"Partitioning the Routing Table" feature was implemented, a properly
configured firewalls, or would the route fail for some other reason?

I think for our use cases we only require Access Control. We are capable
of configuring our firewalls and such correctly. :) Partitioned routing
tables would be nice too but I think a lower priority.

Mike

On Mon, Jan 23, 2017 at 6:24 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation segments
for your use cases, we'd like to know whether you would be inclined to use
dedicated routing tiers for isolation groups in production without the
proposed enhancements below, or whether you would require either/both of
the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an
isolated pool of Diego Cells. On its own, this design will rely on a shared
routing tier with access to all isolation segments. This requires an
operator to carefully configure their load balancer and firewall rules to
prevent an attacker using a spoofed Host header to reach an application
that shouldn't be publicly routable.

An operator can currently deploy dedicated deployments of routers for an
isolation segment but the routing table will be shared among them. Should a
misconfigured load balancer forward a request to routers for an app on
another isolation segment, the routers will attempt to route the request.
If the firewall is correctly configured, the router will return a 502. If
the firewall is misconfigured, a private app may be publicly accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation
segment will only route requests for apps in an associated isolation
segment; if a load balancer were misconfigured, and a request for an app in
another isolation segment were forwarded to the routers, a 404 would be
returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A space
is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.
foo.example.com at routers for isolation segment IS-1 and *.
bar.example.com at routers for isolation segment IS-2, there's nothing
preventing an app developer from creating a route from domain
foo.example.com in a space associated with IS-2. Requests to the route
will fail and the developer would not know why. To prevent this, we'll
enable API clients to filter domains by targeted space, so that a developer
only sees domains from which they can create working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements for
routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Last week the CF Routing team incepted on enhancements for dedicated
deployments of the CF routers for isolation segments.

- Original proposal
<https://docs.google.com/document/d/1FFW8YwKeBK1DuSXFHH_wxGpSZpOpkPN5yOUB-03whsI/edit?usp=sharing>
- Summary
<https://docs.google.com/presentation/d/1D4aguVXHtTGdhFPAqAC1exZd0Nrh2o4VO3PR4kmHvq4/edit?usp=sharing>


For those of you who are looking forward to leveraging isolation segments
for your use cases, we'd like to know whether you would be inclined to use
dedicated routing tiers for isolation groups in production without the
proposed enhancements below, or whether you would require either/both of
the enhancements we have in mind.

*Current Support*

With compute-only isolation, an application can be deployed to an isolated
pool of Diego Cells. On its own, this design will rely on a shared routing
tier with access to all isolation segments. This requires an operator to
carefully configure their load balancer and firewall rules to prevent an
attacker using a spoofed Host header to reach an application that shouldn't
be publicly routable.

An operator can currently deploy dedicated deployments of routers for an
isolation segment but the routing table will be shared among them. Should a
misconfigured load balancer forward a request to routers for an app on
another isolation segment, the routers will attempt to route the request.
If the firewall is correctly configured, the router will return a 502. If
the firewall is misconfigured, a private app may be publicly accessible.

*Proposed Enhancement: Partitioning the Routing Table*

By partitioning the routing table, routers dedicated to a isolation
segment will only route requests for apps in an associated isolation
segment; if a load balancer were misconfigured, and a request for an app in
another isolation segment were forwarded to the routers, a 404 would be
returned.

*Proposed Enhancement: **Access Control*

An org may have multiple domains and multiple isolation segments. A space
is associated with only one isolation segment.

Example: if the operator has configured their LB to point *.
foo.example.com at routers for isolation segment IS-1 and *.
bar.example.com at routers for isolation segment IS-2, there's nothing
preventing an app developer from creating a route from domain
foo.example.com in a space associated with IS-2. Requests to the route
will fail and the developer would not know why. To prevent this, we'll
enable API clients to filter domains by targeted space, so that a developer
only sees domains from which they can create working routes.

*Your Feedback*

Please let us know if you would require either of these enhancements for
routing to isolation segments in your production environments.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Hi, all,

I am trying to get a handle on all pending proposals to CF-Extensions as
well as anything proposed to CF that is now orphaned or would like to be
considered in the CF-Extensions PMC. I have a list [1], however, I am sure
it is not complete.

Please, if you have a proposal pending fitting above and it's not listed
please add it or respond here or to me directly so I add and start tracking.

Thanks,

[1] https://docs.google.com/document/d/1aKmxFdGC4GnXBIZMx0qdIawHrEIRS
jBOzB-spoPlbM8/edit?usp=sharing

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org

You may also want to look into [1] .user.ini files.

+Steven

Would you consider compiling PHP with this option:

--with-config-file-scan-dir /home/vcap/app/php/etc/php.d

And then providing some mechanism for the buildpack to copy .ini files
from a known location into that directory?

[1] http://php.net/manual/en/configuration.file.per-user.php
--
Nicholas Calugar

On January 20, 2017 at 5:36:45 AM, Daniel Mikusa (dmikusa(a)pivotal.io)
wrote:

You can include a `.profile.d/` script or a `.profile` script. It depends
on exactly what you're trying to do as to which one would be better to use,
but I believe most of the time you'd want the `.profile` script. You can
see more about it in the docs here.

https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html#profile

You can essentially do whatever you want in this script. Plus you'll have
access to everything that the PHP build pack has configured for you and
you'll have access to all the environment variables. This means you can
run PHP scripts or examine VCAP_SERVICES. The only catch is that these
scripts runs prior to your application starting so they must run and your
application must start within the defined timeout (default 60s, max 180s on
most platforms).

If you want to integrate with the build pack and do something during
staging or if you need more time (cause staging typically runs for up to
900s), you can add a build pack extension. These are written in Python and
run as a part of the build pack. Instructions on doing that can be found
here.

https://github.com/cloudfoundry/php-buildpack#extensions

Hope that helps!

Dan

On Thu, Jan 19, 2017 at 4:01 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

I have a php monolith app that requires tons of .ini files config
previous to the deployment I want to know if any of you have a "best
practice" to generate all this ini files depending from the environmental
variables.