Is there any provision for restricting the source IPs that are allowed to access a certain application (or route)? Or the only way to do this is to place a reverse proxy in front of the gorouter?
In case the reverse proxy is the only way to go, would there be interest to have something like this implemented inside the gorouter itself? (we're willing to contribute)

What about https://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html
?

On Fri, Oct 30, 2015 at 4:21 PM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

Is there any provision for restricting the source IPs that are allowed to
access a certain application (or route)? Or the only way to do this is to
place a reverse proxy in front of the gorouter?
In case the reverse proxy is the only way to go, would there be interest
to have something like this implemented inside the gorouter itself? (we're
willing to contribute)

Gwenn,

If I'm not wrong Application sec rules are for restricting outbound traffic
from application side , no?

Ronak

Oh right I misread it I thought it was avoid application to connect to
certain IP.....

On Fri, Oct 30, 2015 at 4:46 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Gwenn,

If I'm not wrong Application sec rules are for restricting outbound
traffic from application side , no?

Ronak

On Fri, Oct 30, 2015, 16:38 Gwenn Etourneau <getourneau(a)pivotal.io> wrote:

What about
https://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html ?

On Fri, Oct 30, 2015 at 4:21 PM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

Is there any provision for restricting the source IPs that are allowed
to access a certain application (or route)? Or the only way to do this is
to place a reverse proxy in front of the gorouter?
In case the reverse proxy is the only way to go, would there be interest
to have something like this implemented inside the gorouter itself? (we're
willing to contribute)

We have proprietarily implemented the feature into Gorouter, but now similar
functionality will probably achieved by Route Service [1]. There seems
little information [2] about it and I also want to know the progress.

[1]
https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit#heading=h.8djffzes9pnb

[2] https://www.pivotaltracker.com/n/projects/966314


Carlo Alberto Ferraris-2 wrote

Is there any provision for restricting the source IPs that are allowed to
access a certain application (or route)? Or the only way to do this is to
place a reverse proxy in front of the gorouter?
In case the reverse proxy is the only way to go, would there be interest
to have something like this implemented inside the gorouter itself? (we're
willing to contribute)

-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Source-IP-ACLs-tp2518p2544.html
Sent from the CF Dev mailing list archive at Nabble.com.

You could certainly build a route service to support this use case. Users
would create a service instance of the service, configure it to block
specified IPs (on create, bind, or out-of-band), then bind it to the route,
causing requests to the route to be forwarded to the service instance,
which would block the requests or pass them through. All applications
mapped to the route would be protected.

Route Services opens a whole new class of services which could be offered
in the marketplace by exposing an point of extension. Now all these
features don't have be to implemented directly in the router itself.

Our work on support for Route Services has nearly reached MVP. The backend
work is nearly complete, and we've started work on the CLI commands. Soon
we'll publish documentation for service broker authors as well as end users.

I'll also be sending a request for feedback shortly on a header we're using
in the integration that must be handled by the services. With a few changes
we could support standard forwarding proxies as Route Services per the http
rfc, but it comes with tradeoffs. Stay tuned.

For now, you can refer to these docs for info about the Route Services
feature:
- UX proposal:
https://drive.google.com/open?id=1SfwaQ1hnngfopXC_Q24cT6lbo0yFwvbAbPcCPEHeNPY
- Original proposal:
https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing
- Tracker epics: https://www.pivotaltracker.com/epic/show/1884060 and
https://www.pivotaltracker.com/epic/show/2031344

Please let me know if you have any questions.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Thank you for the response, Shannon,

Our work on support for Route Services has nearly reached MVP.

Great!

- UX proposal:
https://drive.google.com/open?id=1SfwaQ1hnngfopXC_Q24cT6lbo0yFwvbAbPcCPEHeNPY
- Original proposal:
https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing
- Tracker epics: https://www.pivotaltracker.com/epic/show/1884060 and
https://www.pivotaltracker.com/epic/show/2031344

I will read them. Thanks.


--
Noburou TANIGUCHI



shannon wrote

You could certainly build a route service to support this use case. Users
would create a service instance of the service, configure it to block
specified IPs (on create, bind, or out-of-band), then bind it to the
route,
causing requests to the route to be forwarded to the service instance,
which would block the requests or pass them through. All applications
mapped to the route would be protected.

Route Services opens a whole new class of services which could be offered
in the marketplace by exposing an point of extension. Now all these
features don't have be to implemented directly in the router itself.

Our work on support for Route Services has nearly reached MVP. The backend
work is nearly complete, and we've started work on the CLI commands. Soon
we'll publish documentation for service broker authors as well as end
users.

I'll also be sending a request for feedback shortly on a header we're
using
in the integration that must be handled by the services. With a few
changes
we could support standard forwarding proxies as Route Services per the
http
rfc, but it comes with tradeoffs. Stay tuned.

For now, you can refer to these docs for info about the Route Services
feature:
- UX proposal:
https://drive.google.com/open?id=1SfwaQ1hnngfopXC_Q24cT6lbo0yFwvbAbPcCPEHeNPY
- Original proposal:
https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing
- Tracker epics: https://www.pivotaltracker.com/epic/show/1884060 and
https://www.pivotaltracker.com/epic/show/2031344

Please let me know if you have any questions.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Sat, Oct 31, 2015 at 1:33 AM, Noburou TANIGUCHI &lt;

dev(a).m001

&gt; wrote:

We have proprietarily implemented the feature into Gorouter, but now
similar
functionality will probably achieved by Route Service [1]. There seems
little information [2] about it and I also want to know the progress.

[1]

https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit#heading=h.8djffzes9pnb

[2] https://www.pivotaltracker.com/n/projects/966314


Carlo Alberto Ferraris-2 wrote

Is there any provision for restricting the source IPs that are allowed

to

access a certain application (or route)? Or the only way to do this is

to

place a reverse proxy in front of the gorouter?
In case the reverse proxy is the only way to go, would there be

interest

to have something like this implemented inside the gorouter itself?

(we're

willing to contribute)

-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Source-IP-ACLs-tp2518p2544.html
Sent from the CF Dev mailing list archive at Nabble.com.

-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Source-IP-ACLs-tp2518p2628.html
Sent from the CF Dev mailing list archive at Nabble.com.

Our use case include restricting access to some hostnames on the system domain (e.g. api/login/etc.) as well as others that we may add externally. From a cursory read of the proposed spec it sounds like route services are designed to be bound to apps running in CF, so IIUC it wouldn't be possible to deny/allow connections to non-app endpoints.

For apps/services hosted on the system domain that get their route by
publishing to nats or the routing-api, I believe it only requires
registering the route with the additional route_service_url. See the
routing-api-cli [1] for example usage.

As for api, login, etc, many of these components are now using a shared
route registrar job. I could imagine that job being extended to take a
configurable route_service_url.

As an FYI, I've been considering using route services for cloud controller
for rate limiting in the future.

[1] https://github.com/cloudfoundry-incubator/routing-api-cli

On Mon, Nov 9, 2015 at 8:56 PM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

Our use case include restricting access to some hostnames on the system
domain (e.g. api/login/etc.) as well as others that we may add externally.
From a cursory read of the proposed spec it sounds like route services are
designed to be bound to apps running in CF, so IIUC it wouldn't be possible
to deny/allow connections to non-app endpoints.