Date   

CloudFoundry PCI-DSS compliance issue?

Sze Siong Teo <szesiong@...>
 

Hi,

Does anyone have experience deploying CloudFoundry in an environment that requires PCI-DSS compliance?

Would be great to hear from anyone regarding that like how to overcome the concern of firewall whitelisting of entire CF network subnet while complying with PCI DSS requirement.

Thanks in advance.


Re: Proposal for named service bindings

Mike Youngstrom
 

The proposal still has my vote FWIW. :)

Mike

On Sat, Apr 1, 2017 at 7:11 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

The approach with tags has some issues too:
- User-provided services have no tags
- Ambiguous. Tags are not unique so it is possible that the same tag
appears in multiple service instances bound to the same app
- It is possible that different apps put different meaning in the same
tag. This can lead to problems if a service instance with this tag is bound
to these apps.

Generally service bindings act as input to applications, similar to
function arguments. Usually we want to name each input so it has a clear
purpose.

So, please consider again the proposal to add name on service bindings.


On Wed, Mar 15, 2017 at 9:06 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Ok, this might work.
Will try it.

Thanks for the update.

On Wed, Mar 15, 2017 at 12:54 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

I spot a CLI question?



But if you have created a service instance and later you want to bind
it to a new app, can you add the tag expected by that app to the existing
service instance?



`cf update-service mydb -t "list, of, tags"`

http://cli.cloudfoundry.org/en-US/cf/update-service.html



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI





*From:* Peter Dotchev [mailto:dotchev(a)gmail.com]
*Sent:* Tuesday, March 14, 2017 6:17 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] Re: Re: Re: Proposal for named service bindings



Yes, tags at service instance level could work.

But if you have created a service instance and later you want to bind it
to a new app, can you add the tag expected by that app to the existing
service instance?

Also tags do not identify a service instance uniquely, so it is still
possible that an app is bound to multiple instances with the same tag.

I have seen many apps that scan VCAP_SERVICES for a service with
specific properties and pick the first match. This is error prone as there
could be multiple matches.



So I think binding names would be more explicit and tags seem more like
a workaround.





On Mon, Mar 13, 2017 at 9:22 PM, Greg Cobb <gcobb(a)pivotal.io> wrote:

One can supply arbitrary tags for service instances: https://apidocs.clo
udfoundry.org/253/service_instances/creating_a_service_instance.html.
This is not at the binding level, but you could tag your instances as
"secure" and filter on that. Does this help your use case?



On Sun, Mar 12, 2017 at 5:04 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is a great idea. Today to get around this issue my org names our
service instances with a #value at the end and we use custom VCAP_SERVICES
client libraries to ignore anything after the #. That allows us to have a
service named oracle-db#dev and oracle-db#test both be found in
configuration with the name "oracle-db". This proposal would fix that
issue for my org.



Mike



On Sun, Mar 12, 2017 at 4:02 PM, Peter Dotchev <dotchev(a)gmail.com>
wrote:

Hi,



Selecting the right service binding from application code in Cloud
Foundry is often ambiguous and error prone. To address this, I propose to
introduce a service binding name.



The proposal is described in details here

https://github.com/dotchev/cf-named-binding



Looking forward to your comments.



Best regards,

Peter









Re: Proposal for named service bindings

Peter Dotchev <dotchev@...>
 

The approach with tags has some issues too:
- User-provided services have no tags
- Ambiguous. Tags are not unique so it is possible that the same tag
appears in multiple service instances bound to the same app
- It is possible that different apps put different meaning in the same tag.
This can lead to problems if a service instance with this tag is bound to
these apps.

Generally service bindings act as input to applications, similar to
function arguments. Usually we want to name each input so it has a clear
purpose.

So, please consider again the proposal to add name on service bindings.

On Wed, Mar 15, 2017 at 9:06 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Ok, this might work.
Will try it.

Thanks for the update.

On Wed, Mar 15, 2017 at 12:54 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

I spot a CLI question?



But if you have created a service instance and later you want to bind it
to a new app, can you add the tag expected by that app to the existing
service instance?



`cf update-service mydb -t "list, of, tags"`

http://cli.cloudfoundry.org/en-US/cf/update-service.html



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI





*From:* Peter Dotchev [mailto:dotchev(a)gmail.com]
*Sent:* Tuesday, March 14, 2017 6:17 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] Re: Re: Re: Proposal for named service bindings



Yes, tags at service instance level could work.

But if you have created a service instance and later you want to bind it
to a new app, can you add the tag expected by that app to the existing
service instance?

Also tags do not identify a service instance uniquely, so it is still
possible that an app is bound to multiple instances with the same tag.

I have seen many apps that scan VCAP_SERVICES for a service with specific
properties and pick the first match. This is error prone as there could be
multiple matches.



So I think binding names would be more explicit and tags seem more like a
workaround.





On Mon, Mar 13, 2017 at 9:22 PM, Greg Cobb <gcobb(a)pivotal.io> wrote:

One can supply arbitrary tags for service instances: https://apidocs.clo
udfoundry.org/253/service_instances/creating_a_service_instance.html.
This is not at the binding level, but you could tag your instances as
"secure" and filter on that. Does this help your use case?



On Sun, Mar 12, 2017 at 5:04 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is a great idea. Today to get around this issue my org names our
service instances with a #value at the end and we use custom VCAP_SERVICES
client libraries to ignore anything after the #. That allows us to have a
service named oracle-db#dev and oracle-db#test both be found in
configuration with the name "oracle-db". This proposal would fix that
issue for my org.



Mike



On Sun, Mar 12, 2017 at 4:02 PM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi,



Selecting the right service binding from application code in Cloud
Foundry is often ambiguous and error prone. To address this, I propose to
introduce a service binding name.



The proposal is described in details here

https://github.com/dotchev/cf-named-binding



Looking forward to your comments.



Best regards,

Peter









Re: Incubation Proposal - haproxy-boshrelease

Krannich, Bernd <bernd.krannich@...>
 

Same here. From the SAP side, we are also big fans of the haproxy-boshrelease and very much support this proposal.

Regards,
Bernd

Bernd Krannich
SAP Cloud Platform
SAP SE
Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum<http://www.sap.com/company/legal/impressum.epx/>

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


From: Gwenn Etourneau <getourneau(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Friday, 31. March 2017 at 02:18
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Incubation Proposal - haproxy-boshrelease

Nice ! Hope this release will be able to make it.

On Fri, Mar 31, 2017 at 1:48 AM, Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>> wrote:
Outstanding! This is a pretty important component of so many deployments. Really happy to see the S&W version come into the fold.
On Thu, Mar 30, 2017 at 6:46 PM Dieu Cao <dcao(a)pivotal.io<mailto:dcao(a)pivotal.io>> wrote:
Very excited to start the process for incubation to the Runtime PMC for this project!
Will reach out to you with details on bringing this forth for a vote at the next Runtime PMC meeting.

-Dieu

Runtime PMC Lead

On Thu, Mar 30, 2017 at 6:30 AM, Geoff Franks <geoff(a)starkandwayne.com<mailto:geoff(a)starkandwayne.com>> wrote:
Hey All,

We would like to propose https://github.com/cloudfoundry-community/haproxy-boshrelease for the incubation process. It would be a good fit for the Runtime PMC to get a supportable HAProxy solution with support for SNI, internal-domain-restrictions, WSS support, and more. It's been maintained for the past couple years by Stark & Wayne, with some awesome contributions from Orange, Hybris, Pivotal and more!

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815<tel:(267)%20250-0815>


Re: Cloud foundry deployment on vSphere : help on stub file parameters

David Sabeti
 

1. Oh, I was hoping you wouldn't ask! The manifest generation scripts
expect that you have two networks: `cf1` and `cf2`. In order to deploy to a
single network, you can "trick" the scripts into thinking that your single
network is actually two networks:
```
networks:
- name: cf1
type: manual
subnets:
- range: ...
....
- name: cf2
type: manual
subnets: (( networks.cf1.subnets )) # Alias cf1 to cf2 to satisfy
manifest generation
```
For this to deploy successfully, you'll have to reduce the instance count
of all *_z2 jobs to 0. *I should mention that this is very atypical and I
would suggest that you deploy with two networks instead.*

2. Yeah, writing scripts is always nicer than manual work. If you need more
help, you could also look at the cf-release scripts
<https://github.com/cloudfoundry/cf-release/tree/master/scripts> for
generating certs. Also, cf-deployment (what we will eventually use to
replace the manifest generation scripts) declares
<https://github.com/cloudfoundry/cf-deployment/blob/master/cf-deployment.yml#L1220-L1450>
how to generate those certs as well -- I should emphasize that
cf-deployment is still being tested and not ready for general consumption,
but you look there for help with the certs.

For the consul-certs script, make sure you have an up-to-date cf-release
and have run `scripts/update` to sync all the submodules. Once that's done,
you should find the script in the scripts directory
<https://github.com/cloudfoundry/cf-release/blob/master/scripts/generate-consul-certs>
with everything else.

For the jwt signing key, I'm pretty sure you don't need to generate an x509
certificate. Instead, all you want is a simple RSA private key:
```
openssl genrsa -out privatekey 1024
```

For HM9000 configuration, follow the same stub. You should generate the
following values:
- HM9000_SERVER_KEY
- HM9000_SERVER_CERT
- HM9000_CLIENT_KEY
- HM9000_CLIENT_CERT
- HM9000_CA_CERT
Again, you can use the scripts
<https://github.com/cloudfoundry/cf-release/blob/master/scripts/generate-hm9000-certs>
in cf-release.

For the remaining certs (etcd, statsd injector, and uaa), you should
generate those certs as well, again, using the scripts in cf-release. This
doc
<https://github.com/cloudfoundry/cf-release/blob/develop/on-tls-certificates.md>
tries to explain how to generate all of the necessary certificates for CF.
Unfortunately, the docs get stale because they lag behind when we add new
required certificates.

Hope that helps!
David

On Wed, Mar 29, 2017 at 8:37 AM Marc-Laurent Delaruelle <
marc-laurent.delaruelle(a)renault.com> wrote:

Hi,
Thank you very much.

1. What do you mean : To deploy 1 network, you'll need to put something
strange in your stub ? What is the strange thing to add ?

2. I also go forward in the stub file building with : URL
http://docs.cloudfoundry.org/deploying/common/vsphere-vcloud-cf-stub.html
Adding all the certificate is painfull. So I decided to write a code to
automate the inserts of the cert/keys in the stub. I share it at the end of
this mail. The script read a data file with the key=filepath to insert them
with the right indent. As I'm a newbie I don't dare to put it in Github...
:-)

About the URL
- In http://docs.cloudfoundry.org/deploying/common/consul-security.html,
it is said to use scripts/generate-consul-certs. But theses scripts are not
presents in the cf-release. I found them here

https://github.com/cloudfoundry-incubator/consul-release/archive/45e03acbbb993ac0cb93c1996406a31c5682ce39.zip
I don't know if I'm rigth to use them or if I miss something.

- For jwt, it is said to create the key using this command : openssl rsa
-in jwt-key.pem -pubout > key.pub, But the private jw-key.pem do not
exists. So I did
openssl req -x509 -nodes -newkey rsa:2048 -days 365 -keyout key.pem -out
cert.pem
openssl rsa -in key.pem -pubout > key.pub
Right ?

- For hm9000: doc says to setup theses,
ca_cert: HM9000_CA_CERT
server_cert: HM9000_SERVER_CERT
server_key: HM9000_SERVER_KEY
agent_cert: HM9000_AGENT_CERT
agent_key: HM9000_AGENT_KEY
But the stub sample file have something different :
hm9000:
server_key: HM9000_SERVER_KEY
server_cert: HM9000_SERVER_CERT
client_key: HM9000_CLIENT_KEY
client_cert: HM9000_CLIENT_CERT
ca_cert: HM9000_CA_CERT
Do I need to setup all CERT/KEY of the sample stub (including
HM9000_CLIENT_*) as stated in the sample stub file or setup only those
documented and remove the HM9000_CLIENT_* entries ?

- etcd : in the sample stub file, there is
But nothing is said about thes CERT/KEY in the url. cf-release have a
script to generate them. But do I need to use it and put the certificates
in the stub ??
etcd:
require_ssl: true
ca_cert: ETCD_CA_CERT
client_cert: ETCD_CLIENT_CERT
client_key: ETCD_CLIENT_KEY
peer_ca_cert: ETCD_PEER_CA_CERT
peer_cert: ETCD_PEER_CERT
peer_key: ETC_PEER_KEY
server_cert: ETCD_SERVER_CERT
server_key: ETCD_SERVER_KEY

- Same for
statsd_injector: (script to create certs exists)
cert: LOGGREGATOR_STATSDINJECTOR_CERT
key: LOGGREGATOR_STATSDINJECTOR_KEY
uaa:
admin: (script to create certs exists)
client_secret: ADMIN_SECRET
ca_cert: UAA_CA_CERT
scim
sslCertificate: UAA_SERVER_CERT
sslPrivateKey: UAA_SERVER_KEY
___________________________
SCRIPT :

# Make a backup
DATE=`date +%Y-%m-%d-%H%M%S`
stubfile=~/automation/CfManifestStub.yml
cp $stubfile $stubfile.$DATE.yml
stubfile=$stubfile.$DATE.yml
echo $stubfile
#cp ~/CfManifestStub.yml ~/CfManifestStub.yml.bak
# Generate certificates
cd ~/cf-release
#./cf-release-master/scripts/generate-cf-diego-certs

#./consul-release/consul-release-45e03acbbb993ac0cb93c1996406a31c5682ce39/scripts/generate-certs
#./cf-release-master/scripts/generate-loggregator-certs
cf-diego-certs/cf-diego-ca.crt cf-diego-certs/cf-diego-ca.key
#mkdir ~/cf-release/http;cd ~/cf-release/http
#openssl req -x509 -nodes -newkey rsa:2048 -days 365 -keyout key.pem -out
cert.pem
# leave everything as default. You get 2 files cert.pem and key.pem
#mkdir ~/cf-release/jwt;cd ~/cf-release/jwt
#openssl req -x509 -nodes -newkey rsa:2048 -days 365 -keyout key.pem -out
cert.pem
#openssl rsa -in key.pem -pubout > key.pub
#./cf-release-master/scripts/generate-hm9000-certs
#mkdir jobs;cd jobs
#openssl req -x509 -nodes -newkey rsa:2048 -days 365 -keyout key.pem -out
cert.pem
# enter for hostname *.cff.pocx86.tstwinx.net
cd ~/automation
while read line ; do
IFS='='; entry=($line); unset IFS
echo "Adding data for ${entry[0]}"
#get the number of leading spaces of the lines with the tag to replace by
cert/key then add 2 spaces for json
blanks=$(grep "${entry[0]}" $stubfile | awk -F'[^ ]' '{print length($1)}')
blanks=$(($blanks+2))
#add the number of blanks to the file of the cert/key
temp=${entry[1]}
echo "temp=$temp"
awk '{printf "%"'$blanks'"s%s\n", "", $0}' "${entry[1]}" > /tmp/entry.tmp
cat /tmp/entry.tmp
#insert the file in the stub file under the tag to replace
sed -i '/'${entry[0]}'/r /tmp/entry.tmp' $stubfile
# remove the tag and add the |
sed -i 's/'${entry[0]}'/|/' $stubfile
done < tag-files.txt
# Adding the 2 last keys
# First removing the comments
head --lines=-6 $stubfile > /tmp/file.tmp
mv /tmp/file.tmp $stubfile
cat $stubfile
# Adding the keys
awk '{printf "%"'8'"s%s\n", "", $0}' ../cf-release/jobs/key.pem >
/tmp/entry1.tmp
awk '{printf "%"'8'"s%s\n", "", $0}' ../cf-release/jobs/cert.pem >
/tmp/entry2.tmp
cat $stubfile /tmp/entry1.tmp /tmp/entry2.tmp > /tmp/file.tmp
rm /tmp/entry1.tmp;rm /tmp/entry2.tmp
mv /tmp/file.tmp $stubfile
echo $stubfile updated with certificates/keys

[bosh(a)jumpboxcf automation]$ cat tag-files.txt
CC_MUTUAL_TLS_CA_CERT=../cf-release/cf-diego-certs/cf-diego-ca.crt
CC_MUTUAL_TLS_PUBLIC_CERT=../cf-release/cf-diego-certs/cloud-controller.crt
CC_MUTUAL_TLS_PRIVATE_KEY=../cf-release/cf-diego-certs/cloud-controller.key
CONSUL_CA_CERT=../cf-release/consul-certs/server-ca.crt
CONSUL_SERVER_CERT=../cf-release/consul-certs/server.crt
CONSUL_SERVER_KEY=../cf-release/consul-certs/server.key
CONSUL_AGENT_CERT=../cf-release/consul-certs/agent.crt
CONSUL_AGENT_KEY=../cf-release/consul-certs/agent.key
LOGGREGATOR_CA_CERT=../cf-release/loggregator-certs/loggregator-ca.crt
LOGGREGATOR_DOPPLER_CERT=../cf-release/loggregator-certs/doppler.crt
LOGGREGATOR_DOPPLER_KEY=../cf-release/loggregator-certs/doppler.key

LOGGREGATOR_TRAFFICCONTROLLER_CERT=../cf-release/loggregator-certs/trafficcontroller.crt

LOGGREGATOR_TRAFFICCONTROLLER_KEY=../cf-release/loggregator-certs/trafficcontroller.key
LOGGREGATOR_METRON_CERT=../cf-release/loggregator-certs/metron.crt
LOGGREGATOR_METRON_KEY=../cf-release/loggregator-certs/metron.key

LOGGREGATOR_SYSLOGDRAINBINDER_CERT=../cf-release/loggregator-certs/syslogdrainbinder.crt

LOGGREGATOR_SYSLOGDRAINBINDER_KEY=../cf-release/loggregator-certs/syslogdrainbinder.key
SERVICE_PROVIDER_PRIVATE_KEY=../cf-release/http/key.pem
JWT_VERIFICATION_KEY=../cf-release/jwt/key.pem
JWT_SIGNING_KEY=../cf-release/jwt/key.pub
HM9000_CA_CERT=../cf-release/hm9000-certs/hm9000_ca.crt
HM9000_SERVER_CERT=../cf-release/hm9000-certs/hm9000_server.crt
HM9000_SERVER_KEY=../cf-release/hm9000-certs/hm9000_server.key
HM9000_AGENT_CERT=../cf-release/hm9000-certs/hm9000_client.crt
HM9000_AGENT_KEY=../cf-release/hm9000-certs/hm9000_client.key
[bosh(a)jumpboxcf automation]$





Re: CF environmental variables - org is missing

Noburou TANIGUCHI
 

Sorry for resurrecting an old thread.

Is there any progress on this issue?
Recently one of our users also needs to get org and space info from
environment variables.

I've checked the story[1] Nick mentioned, but it seems still in the icebox.
What is required to gear up its progress?

[1] https://www.pivotaltracker.com/story/show/126180869

Regards,


Nicholas Calugar wrote
Hi Vinod,

We are actually intending to deprecate VCAP_APPLICATION in favor of CF_
environment variables in the near future:

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


Thanks,

Nick

--
Nicholas Calugar

On October 13, 2016 at 8:20:21 AM, Vinod Singh (
vinoddandy@
) wrote:

Friends,

I am working to retrieve org/space/application-name in CF via System
provided environmental variables.
Unfortunately I could not "org" in list. Is it not a good idea to include
"org" also in System Provided list ?

cf env
<appname>
System-Provided:


{
"VCAP_APPLICATION": {
"application_id": "74b3e1a6-ba9f-4dcb-9ae3-e68e1dbfa417",
"application_name": "mylogapp",
"application_uris": [
"xxxx.xxxx.xxx"
],
"application_version": "e43c2d12-cd8e-46d3-9298-ce0905651c0e",
"limits": {
"disk": 1024,
"fds": 16384,
"mem": 128
},
"name": "mylogapp",
"space_id": "4d942c57-e41e-43e2-ba3a-0665ceaa976b",
"space_name": "demo2",
"uris": [
"xxxxx.xxxxx.xxxxx"
],
"users": null,
"version": "e43c2d12-cd8e-46d3-9298-ce0905651c0e"
}
}


Regards,
Vinod




-----
I'm not a ...
Noburou TANIGUCHI
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-CF-environmental-variables-org-is-missing-tp5914p6678.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Accessing 192.168.x.x addresses from a diego_cell container

Ross Mark
 

Thank you Eric for the quick response.

That was exactly the information I required.

I'm finding there is so much information to absorb a lot of the issue is just finding the right topic to look under.

Thanks again.

Ross


Re: CF install on vSphere

Mike Dalessio
 

Hi Marc-Laurent,

You're asking some great questions! It might be easier for people to help
you out if you join the slack:

http://slack.cloudfoundry.org/


as many of these questions can be answered many ways, depending on your
specific situation.

Hope to see you on the slack!

-mike


On Fri, Mar 24, 2017 at 12:57 PM, Marc-Laurent Delaruelle <
marc-laurent.delaruelle(a)renault.com> wrote:

Hi all,

I installed Bosh 261.4.0 and now I would like to install Cloud Foundry :-)

So I'm reading : https://docs.cloudfoundry.org/deploying/common/vsphere-
vcloud-cf-stub.html to create the .yml file for bosh to deploy cf.
But, it's may not the right page to have details on all the parameters of
this file

About networks : the page says :
- This examples assumes a two-network deployment. Ok, but may I deploy on
1 network, 3 networks ? In fact what are the rules to decide how many
networks are required.
- reserved : means the range is forbidden for cloud foundry ?
- static : means cloud foundry may use theses IP without DHCP ?

About system domain and system domain organization : it is said : You must
have <...> configured their DNS records so that these domains resolve to
your load balancer.
So do that means I need of a load balancer prior to deploy cloud foundry ?
Ha-proxy is a LB. So how to deploy ha-proxy with bosh ?
I think I need of a .yml file specifying vip and the adresses of the
routers of cf.
It would be great to deploy ha-proxy and cf in the same .yml in fact.
BTW : what is a system domain organization ?

After deploying it, will I get a GUI to manage users, spaces and orgs ?

Thanks for any help !
MLD


Re: Incubation Proposal - haproxy-boshrelease

Gwenn Etourneau
 

Nice ! Hope this release will be able to make it.

On Fri, Mar 31, 2017 at 1:48 AM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

Outstanding! This is a pretty important component of so many deployments.
Really happy to see the S&W version come into the fold.
On Thu, Mar 30, 2017 at 6:46 PM Dieu Cao <dcao(a)pivotal.io> wrote:

Very excited to start the process for incubation to the Runtime PMC for
this project!
Will reach out to you with details on bringing this forth for a vote at
the next Runtime PMC meeting.

-Dieu

Runtime PMC Lead

On Thu, Mar 30, 2017 at 6:30 AM, Geoff Franks <geoff(a)starkandwayne.com>
wrote:

Hey All,

We would like to propose https://github.com/cloudfoundry-community/
haproxy-boshrelease for the incubation process. It would be a good fit
for the Runtime PMC to get a supportable HAProxy solution with support for
SNI, internal-domain-restrictions, WSS support, and more. It's been
maintained for the past couple years by Stark & Wayne, with some awesome
contributions from Orange, Hybris, Pivotal and more!


--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>


Re: Abacus UI

Hristo Iliev
 

We plan to have an UI as part of the Abacus Broker project [1].

ATM we are implementing the back-end APIs to support a service broker and
UI for editing Abacus plans. We are half-way through the the work for this
self-service MVP. We just started the broker and done first mock-ups for
the self-service UI. You can follow the progress in tracker [2]

We sketched ideas for reporting (drill-down for your org) and operations
(all orgs statistics) UIs, which might be of interest to you. For now these
are with just ideas and with lower prio, but I guess we can post a proposal
to discuss the general direction in broader round.

Feel free to reply with requirements, question or ideas for functionality
you want to see.

Regards,
Hristo Iliev

[1] https://github.com/cloudfoundry-incubator/cf-abacus-broker
[2] https://www.pivotaltracker.com/n/projects/1968575

2017-03-30 20:29 GMT+03:00 Rajesh Jain <rjain15(a)gmail.com>:

https://github.com/cloudfoundry-incubator/cf-abacus

Is there a UI/Dashboard with Reports on top of Abacus?


--
@rjain15


Abacus UI

Rajesh Jain <rjain15@...>
 

https://github.com/cloudfoundry-incubator/cf-abacus

Is there a UI/Dashboard with Reports on top of Abacus?


--
@rjain15


Re: Incubation Proposal - haproxy-boshrelease

Chip Childers <cchilders@...>
 

Outstanding! This is a pretty important component of so many deployments.
Really happy to see the S&W version come into the fold.
On Thu, Mar 30, 2017 at 6:46 PM Dieu Cao <dcao(a)pivotal.io> wrote:

Very excited to start the process for incubation to the Runtime PMC for
this project!
Will reach out to you with details on bringing this forth for a vote at
the next Runtime PMC meeting.

-Dieu

Runtime PMC Lead

On Thu, Mar 30, 2017 at 6:30 AM, Geoff Franks <geoff(a)starkandwayne.com>
wrote:

Hey All,

We would like to propose
https://github.com/cloudfoundry-community/haproxy-boshrelease for the
incubation process. It would be a good fit for the Runtime PMC to get a
supportable HAProxy solution with support for SNI,
internal-domain-restrictions, WSS support, and more. It's been maintained
for the past couple years by Stark & Wayne, with some awesome contributions
from Orange, Hybris, Pivotal and more!


--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Incubation Proposal - haproxy-boshrelease

Dieu Cao <dcao@...>
 

Very excited to start the process for incubation to the Runtime PMC for
this project!
Will reach out to you with details on bringing this forth for a vote at the
next Runtime PMC meeting.

-Dieu

Runtime PMC Lead

On Thu, Mar 30, 2017 at 6:30 AM, Geoff Franks <geoff(a)starkandwayne.com>
wrote:

Hey All,

We would like to propose https://github.com/cloudfoundry-community/
haproxy-boshrelease for the incubation process. It would be a good fit
for the Runtime PMC to get a supportable HAProxy solution with support for
SNI, internal-domain-restrictions, WSS support, and more. It's been
maintained for the past couple years by Stark & Wayne, with some awesome
contributions from Orange, Hybris, Pivotal and more!


Re: Accessing 192.168.x.x addresses from a diego_cell container

Eric Malm <emalm@...>
 

Hi, Ross,

Thanks for asking about this. Rules for traffic egressing CF containers are
controlled by whitelist-style security groups defined in CC and bound
either system-wide or to individual spaces. The docs for configuring them
are located at http://docs.cloudfoundry.org/adminguide/app-sec-groups.html.

The default security groups allow DNS traffic anywhere (port 53 on TCP and
UDP) and traffic to public IP space, which are seeded in the minimal
manifest at https://github.com/cloudfoundry/cf-release/blob/
v254/example_manifests/minimal-aws.yml#L631-L642 and which correspond
to the rules you see in that iptables output. So in your case, you'll need
to add a security group for access to the VPN network in private IP space
and bind it system-wide as both a staging and a running security group.
Here are the steps you would take to do that with the CF CLI as an admin
user:

- Create a "vpn" security group with the cf create-security-group command,
which involves putting the security group definition into a file and
supplying that to the command:

echo '[{"protocol":"all","destination":"192.168.0.0/24","description":"VPN"}]'
vpn.json
cf create-security-group vpn vpn.json

If you use bash or a similar shell with process substitution, you can
inline the definition instead of creating that separate file:

cf create-security-group vpn <(echo '[{"protocol":"all","destination":"
192.168.0.0/24","description":"VPN"}]')

- Bind that new "vpn" security group system-wide:

cf bind-staging-security-group vpn
cf bind-running-security-group vpn

You'll then have to restart the apps for the new security group rules to
take effect.

Best,
Eric, CF Diego PM


On Thu, Mar 30, 2017 at 6:57 AM, Ross Mark <ross.mark(a)s4-technology.com>
wrote:

This is my first time setting up bosh and cloud foundry on an AWS
environment. Appologies if I'm asking this in the wrong group.

I've implemented the cf deployment using the minimal-aws.yml example as
basis. The problem I'm facing is that our applications need to access a
remote network via VPN with a 192.168.0.0/24 address. The VPN is working
happily, dns using our own internal dns server is resolving correctly so
the cf deployed containers can resolve the address they need however when
they try and access any of the 192.168.0.x addresses (except dns) the
requests are never forwarded from the internal 10.254.0.2 network. Looking
at the iptables rules on the diego_cell vm (iptables -L -n -v) the problem
appears to be in the w--forward chain which after checking the
w--instance-c56ch9ro828 chain, which generates a RETURN, then DROPS the
request.

What I'm looking for is how to configure the deployment so that network
address 192.168.0.0/24 are ACCEPTED for forwarding. I have tested by
manually adding an ACCEPT rule in the w--forward chain, and there is full
connectivity once a rule is added.

The iptables output (trimmed to just include the FORWARD chains) is below.

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
327 36110 w--forward all -- w+ * 0.0.0.0/0
0.0.0.0/0

Chain w--forward (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- eth0 * 0.0.0.0/0
0.0.0.0/0
67 6522 w--instance-c56ch9ro828 all -- wbrdg-0afe0000 *
10.254.0.2 0.0.0.0/0 [goto] /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0

Chain w--instance-c56ch9ro828 (1 references)
pkts bytes target prot opt in out source
destination
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 192.169.0.0-255.255.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
59 5016 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 172.32.0.0-192.167.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 169.255.0.0-172.15.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 11.0.0.0-169.253.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 0.0.0.0-9.255.255.255 /*
275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
4 224 RETURN udp -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 0.0.0.0-255.255.255.255 udp
dpt:53 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN tcp -- * * 0.0.0.0/0
0.0.0.0/0 destination IP range 0.0.0.0-255.255.255.255 tcp
dpt:53 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 ACCEPT all -- * * 10.254.0.0/30
10.254.0.0/30 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
4 1282 w--default all -- * * 0.0.0.0/0
0.0.0.0/0 [goto] /* 275382a7-82d6-4d20-7



Thanks in advance.

Ross


Accessing 192.168.x.x addresses from a diego_cell container

Ross Mark
 

This is my first time setting up bosh and cloud foundry on an AWS environment. Appologies if I'm asking this in the wrong group.

I've implemented the cf deployment using the minimal-aws.yml example as basis. The problem I'm facing is that our applications need to access a remote network via VPN with a 192.168.0.0/24 address. The VPN is working happily, dns using our own internal dns server is resolving correctly so the cf deployed containers can resolve the address they need however when they try and access any of the 192.168.0.x addresses (except dns) the requests are never forwarded from the internal 10.254.0.2 network. Looking at the iptables rules on the diego_cell vm (iptables -L -n -v) the problem appears to be in the w--forward chain which after checking the w--instance-c56ch9ro828 chain, which generates a RETURN, then DROPS the request.

What I'm looking for is how to configure the deployment so that network address 192.168.0.0/24 are ACCEPTED for forwarding. I have tested by manually adding an ACCEPT rule in the w--forward chain, and there is full connectivity once a rule is added.

The iptables output (trimmed to just include the FORWARD chains) is below.

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
327 36110 w--forward all -- w+ * 0.0.0.0/0 0.0.0.0/0

Chain w--forward (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
67 6522 w--instance-c56ch9ro828 all -- wbrdg-0afe0000 * 10.254.0.2 0.0.0.0/0 [goto] /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain w--instance-c56ch9ro828 (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 192.169.0.0-255.255.255.255 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
59 5016 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 172.32.0.0-192.167.255.255 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 169.255.0.0-172.15.255.255 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 11.0.0.0-169.253.255.255 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 0.0.0.0-9.255.255.255 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
4 224 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 0.0.0.0-255.255.255.255 udp dpt:53 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 0.0.0.0-255.255.255.255 tcp dpt:53 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
0 0 ACCEPT all -- * * 10.254.0.0/30 10.254.0.0/30 /* 275382a7-82d6-4d20-76fd-00e7bf0de5f7 */
4 1282 w--default all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] /* 275382a7-82d6-4d20-7



Thanks in advance.

Ross


Incubation Proposal - haproxy-boshrelease

Geoff Franks <geoff@...>
 

Hey All,

We would like to propose https://github.com/cloudfoundry-community/haproxy-boshrelease <https://github.com/cloudfoundry-community/haproxy-boshrelease> for the incubation process. It would be a good fit for the Runtime PMC to get a supportable HAProxy solution with support for SNI, internal-domain-restrictions, WSS support, and more. It's been maintained for the past couple years by Stark & Wayne, with some awesome contributions from Orange, Hybris, Pivotal and more!


Cloud foundy java client roles

Patrik Kmetcz <kpatryk91@...>
 

Hi!

In the cf cli api program there is this commad:

cf l -a url -o orgnizName -s smoke -u username -p password

I have read the following documentation

https://github.com/cloudfoundry/cf-java-client

and i can connect to the server and get the spaces.

But I need to execute the following command(s):

cf set-space-role email org space role / or unset

In the cloud foundry java client where is this function, because in the
CloudFoundryOperations I only found operations with manage functions, but
there is no command to modify the roles.

If there is any class in these packages wich I can make these change?


Re: [cf-bosh] Re: BOSH Links: Why and How

Amit Kumar Gupta
 

Thanks Nic, your early feedback on that note was helpful, keep it coming if
you have more!

On Wed, Mar 29, 2017 at 3:41 PM, Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

Amit, this doc has been awesomely helpful to me over the last week or so.
I've been steadily upgrading bosh releases. I like them & the deployment
manifests a lot more.


------------------------------
*From:* Amit Gupta <agupta(a)pivotal.io>
*Sent:* Thursday, March 30, 2017 8:35:53 AM
*To:* Discussions about the Cloud Foundry BOSH project.; Discussions
about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] BOSH Links: Why and How

Hi all,

"BOSH Links" is a feature which simplifies how data is shared between
BOSH-deployed jobs that need to collaborate with one another (e.g. a web
server and its backing database). Like many BOSH things, the whole "BOSH
Links" thing can seem counter-intuitive at first, and it may not be clear
why things are the way they are. This note linked below hopes to show some
of the powerful benefits of BOSH Links, and provide examples and
explanations that make things more intuitive.

Hope folks find it useful!

https://gist.github.com/Amit-PivotalLabs/c39528248b8cdc4ba8e347f8aa68abb6

Best,
Amit


Re: BOSH Links: Why and How

Dr Nic Williams <drnicwilliams@...>
 

Amit, this doc has been awesomely helpful to me over the last week or so. I've been steadily upgrading bosh releases. I like them & the deployment manifests a lot more.


________________________________
From: Amit Gupta <agupta(a)pivotal.io>
Sent: Thursday, March 30, 2017 8:35:53 AM
To: Discussions about the Cloud Foundry BOSH project.; Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] BOSH Links: Why and How

Hi all,

"BOSH Links" is a feature which simplifies how data is shared between BOSH-deployed jobs that need to collaborate with one another (e.g. a web server and its backing database). Like many BOSH things, the whole "BOSH Links" thing can seem counter-intuitive at first, and it may not be clear why things are the way they are. This note linked below hopes to show some of the powerful benefits of BOSH Links, and provide examples and explanations that make things more intuitive.

Hope folks find it useful!

https://gist.github.com/Amit-PivotalLabs/c39528248b8cdc4ba8e347f8aa68abb6

Best,
Amit


BOSH Links: Why and How

Amit Kumar Gupta
 

Hi all,

"BOSH Links" is a feature which simplifies how data is shared between
BOSH-deployed jobs that need to collaborate with one another (e.g. a web
server and its backing database). Like many BOSH things, the whole "BOSH
Links" thing can seem counter-intuitive at first, and it may not be clear
why things are the way they are. This note linked below hopes to show some
of the powerful benefits of BOSH Links, and provide examples and
explanations that make things more intuitive.

Hope folks find it useful!

https://gist.github.com/Amit-PivotalLabs/c39528248b8cdc4ba8e347f8aa68abb6

Best,
Amit

2781 - 2800 of 9408