Feature Request: add add-network-policy to manifest

[dustpuppyNGTI]

It is possible to set network policies using the command line:

cf add-network-policy SOURCE_APP --destination-app DESTINATION_APP --protocol (tcp | udp) --port RANGE

However it is not possible to set these values using the manifest. This makes it hard to perform deploys from automated systems.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/159880404

The labels on this github issue will be updated when the story is started.

[abbyachau]

cc @zrob

[zrob]

This is a really interesting request.

I don't know how we'll be able to accommodate it in the server side manifest world. The network policy API is a totally separate entity from the CC.

/cc @rosenhouse @ameowlia @pvaramballypivot

[rosenhouse]

@zrob what is this server-side-manifest-world that you speak of? got a link?

[zrob]

The cli will no longer parse app manifests and translate them to API requests. Instead they will send the yaml to CC and we'll apply it.

Epic: https://www.pivotaltracker.com/epic/show/3867153 API docs: http://v3-apidocs.cloudfoundry.org/version/3.55.0/index.html#app-manifest

[making]

@zrob this feature is pretty important, for example in case of the following situation:

When zero-downtime-updating App B, the following sequences are required:

1. cf rename app-b app-b-venerable
2. cf push app-b
3. cf add-network-policy app-a --destination-app app-b --port 8080
4. cf add-network-policy app-b --destination-app app-c --port 8080
5. cf unmap-route app-b-venerable apps.internal -n app-b
6. cf delete -r -f app-b-venerable

Without a support from cf cli, autopilot plugin is unavailable and it is truoublesome for deploying cf apps in concourse

It would be awesome if we could write something like:

applications:
- name: app-b
  network_policies:
  - source: app-a 
    port: 8080
    protocotl: tcp
  - destination: app-b
    port: 8080
    protocol: tcp

[rosenhouse]

I really like the model of decorating the destination (server) app with the list of allowed source (client) apps. +1 to this UX.

[zrob]

I see how that would be valuable. We'd have to teach CC how to talk to policy server. It has interesting implications for the create-manifest workflow as well.

I also wonder if there's some even simpler workflows if we went deep on CC/policy server integration

For example imagine something like

1. cf create-network networkName
2. cf add-app-to-network appName networkName
3. cf remove-app-from-network appName networkName

manifest something like this instead of using the add/remove commands

applications:
- name: app-b
  networks:
  - networkName
  - otherNetworkName

Would mean you don't have to keep a full list of apps all the time, although maybe the full list is desirable?

[ameowlia]

@zrob, it sounds like rolling deploys would fix @making's use case?

[making]

@zrob +1 for your idea. My proposal will not work in case that App C is not deployed yet such as first deployment. Adding the app to a logical group sounds pretty good

[kzbt]

Will this be considered in the near future?

[ameowlia]

cc/ Networking PM @adobley

[adobley]

@kzbt this is not currently planned, but we have been collecting evidence to help us scope, plan, and prioritize this feature. It is in the pipeline, but I can't give an estimate as to when. If you have a case that isn't captured above, I'd love to hear about it.

[kzbt]

@adobley Our usecase is the same/similar. We have a gateway app that controls all ingress and all internal traffic is using pcf internal routes. This makes add-network-policy a necessity for deployments. It is easy enough to automate it and we have done that in our ci pipelines, but problem arises when doing quick manual deploys to dev environments for testing etc.. because often this step is forgotten or devs don't realize it is required. Making it a declarative option in the manifest would be best as that would describe ideal state of the app in pcf once deployed.

[abbyachau]

Hi all, thanks for everyone's feedback. I'm moving this issue to the CC API's github repo since they are responsible for server side manifests for V3.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/165578018

The labels on this github issue will be updated when the story is started.

[tcdowney]

@adobley @shalako @shubhaat

I believe this isn't currently prioritized work in any of the Networking Program teams' backlogs, but I was wondering if y'all had any stories/feature narratives that could be linked in this issue to help folks track it.

[anishp55]

Has there been any progress on this? My group is currently trying to work through this issue as well

[cwlbraa]

We continue to work on maturing the v3 api and the v7 cli that would enable this feature to be widely consumable via server side manifests. We've got in contact with the #networking program via Slack to see if maybe they've done any work in this scope: https://cloudfoundry.slack.com/archives/CFX13JK7B/p1579724426011600

Folks are also interested in routes in the space manifest: https://github.com/cloudfoundry/capi-release/issues/158

But other than continued conversation I'm not aware of any work being done in this area.

[gbansal3]

hi team,

please confirm if the option to define network policy as part of manifest is already in place or it is in WIP or still in Not Started Phase.

Thanks

[timoknapp]

hi team,

please confirm if the option to define network policy as part of manifest is already in place or it is in WIP or still in Not Started Phase.

Thanks

I am also interested in this. It is a pretty unstable that the network policies are reverted after each redeployment..

[1up-exe]

hi team,

please confirm if the option to define network policy as part of manifest is already in place or it is in WIP or still in Not Started Phase.

Thanks

I'm also interested.

[moleske]

I and @MerricdeLauney were looking at how this would work with rolling deploys. It turns out quite well. When following the rolling app deployments docs, we were able to keep the existing network policies. So to set up the example we ran the following commands

cf push app-a
cf push app-b
cf push app-c
cf add-network-policy app-a app-b
cf add-network-policy app-b app-c

We then deployed a new version of app-b using --strategy rolling with

cf push app-b --strategy rolling

We had zero downtime while app-b was updating and the network policies stayed in place as we were no longer pushing a separate app.

We would be interested in hearing if this solution works for folks whose concern was on zero downtime deployments. This is likely not helpful on pushing an app for the first time.