Date   

Re: UAA: How to set client_credentials token grant type to not expire

Filip Hanik
 

Start a local server (./gradlew run --info)

In another console, the following commands

1. uaac target http://localhost:8080/uaa
2. uaac token client get admin -s adminsecret
3. uaac client add testclient --authorized_grant_types
client_credentials --access_token_validity 315360000 --authorities openid
-s testclientsecret
4. uaac token client get testclient -s testclientsecret
5. uaac token decode

The output from the last command is
jti: 7397c7c9-de08-4b33-bd6a-0d248fd983b1
sub: testclient
authorities: openid
scope: openid
client_id: testclient
cid: testclient
azp: testclient
grant_type: client_credentials
rev_sig: fbc56677
iat: 1438351964
exp: 1753711964
iss: http://localhost:8080/uaa/oauth/token
zid: uaa
aud: testclient openid

The exp time is 1753711964, that is seconds from Jan 1st, 1970, and
corresponds to July 28, 2025

On Fri, Jul 31, 2015 at 12:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Filip,

Here's my client config:
useraccount
scope: clients.read oauth.approvals openid password.write tokens.read
tokens.write uaa.admin
resource_ids: none
authorized_grant_types: authorization_code client_credentials password
refresh_token
authorities: scim.read scim.userids uaa.admin uaa.resource
clients.read scim.write cloud_controller.write scim.me clients.secret
password.write clients.write openid cloud_controller.read oauth.approvals
access_token_validity: 315360000
autoapprove: true

Gotten from `uaac clients`

I really do not know what else I might be doing wrongly.

Does `test_Token_Expiry_Time()` also cover for client_credentials grant
type? I tried running the test with
`./gradlew test
-Dtest.single=org/cloudfoundry/identity/uaa/mock/token/TokenMvcMockTests`
and placed debuggers in order to view the generated expiration time.
Nothing was printed in the test results.


On Wed, Jul 29, 2015 at 6:11 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276

most likely your client does not have the access token validity setup
correctly. See the test case I posted that validates my statements

https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883


On Wed, Jul 29, 2015 at 9:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Good. But my apologies. Assume:

creation time = 1438184877
access token validity (set by me) = 315360000

exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276

On Wed, Jul 29, 2015 at 5:43 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?

It's a little bit different.

access_token_validity is how long the token is valid for from the time
of creation. thus we can derive

exp (expiration time) = token creation time + access token validity

you don't get to set the expiration time, since that doesn't make sense
as the clock keeps ticking forward.

in your case, having access token validity be 10 years, achieves
exactly what you want

Filip


On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Thanks again Filip.

However, here's what I mean,

If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?

line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)

Now the question is why do you have to do expirationTime*1000l since
the token when decoded originally set's this value to 1438209609
(without * 1000l)

Except I'm completely getting this all wrong?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Troubleshooting tips ...

Vish
 

Hi Folks,
I see the below  error , when trying to connect to api end point :
cf api api.cf.fxlab.net --skip-ssl-validation
Setting api endpoint to api.cf.fxlab.net...
FAILED
Server error, status code: 404, error code: 0, message:


This was working yesterday, I already checked that all the cf components are active and running.
Need pointers on where to start the troubleshooting.

Kindly assist.
Regards,Vish.


Re: CF-Abacus: incubation and inception meeting coming soon

Guillaume Berche
 

Any chance to have the google hangout recorded (screen + voice) as to
enable offline replays (similar to CFAD) ?

Thanks,

Guillaume.

On Fri, Jul 31, 2015 at 6:38 AM, Matt Cowger <matt(a)cowger.us> wrote:

Stormy - I will happily blog it and take pictures...but you don't want my
notes...I was always the one in college that borrowed notes.

On Thu, Jul 30, 2015 at 3:37 PM, Stormy Peters <speters(a)cloudfoundry.org>
wrote:

Will somebody be taking notes? Would somebody be willing to blog about
this afterwards?

Maybe take a group picture and summarize what was discussed?

Thanks,

Stormy


On Thu, Jul 30, 2015 at 3:31 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

Here is pertinent information for CF-Abacus inception meeting next
week.

Invites to those interested is sent. If you want to attend physically then ping me or Devin from CFF on CC: since
we need to add you to the list for the WeWork building.

---------
*Date:* Wednesday August 5th, 2015

*Time:* 9:30am - 12:30pm PDT

*Location:*
CloudFoundry Foundation Offices @ WeWork SF on Mission

WeWork
535 Mission St., *19th floor *
San Francisco, CA

*Room:* 19B

*Call info:*
IBM AT&T Conference Call
USA 888-426-6840; 215-861-6239 | Participant code: 1985291
All other countries, find number here: http://goo.gl/RnNfc1

*Hangout:* TBD
---------

Best,

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


*Michael Maximilien/Almaden/IBM*

07/29/2015 11:35 AM
To
"cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
cc
Subject
Re: CF-Abacus: incubation and inception meeting coming soon




Quick update on inception meeting.

To accommodate our friends and colleagues from Europe who would like to
attend, let's plan to move the meeting to 10a to 12:30p with the option of
lunch after at nearby location in SF.

Unless I hear any objections I will send the invites to those interested
parties who have already contacted me and confirm details here.

If you want to attend (local or remote) please remember to reply to me
with email so I can add you to invite list.

Best,

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

On Jul 28, 2015, at 10:15 PM, Michael Maximilien <*maxim(a)us.ibm.com*
<maxim(a)us.ibm.com>> wrote:

Hi, all,

Now that CF-Abacus is officially an incubator under the guidance of the
CFF, here are some quick updates:

1. The project official github moved to:

*https://github.com/cloudfoundry-incubator/cf-abacus*
<https://github.com/cloudfoundry-incubator/cf-abacus>

2. We are planning an inception next week Wednesday from 2p to 5p in SF.

We invite everyone interested to take a look at the repo, provide
feedback, or better, join us at the inception meeting. The location will be
either CFF, Pivotal, or IBM. All within a few blocks in downtown SF.

We will also have Google hangout and conference call for remote
participants.

If interested, then respond to me directly so I add you to the invite
list.

Thanks and talk next week. Best,

CF-Abacus team

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Default cgroup CPU share

Will Pragnell <wpragnell@...>
 

In case it's not clear, shares are not dynamically reallocated to apps when
new apps are deployed. So in the example from the original email, if app #1
initially has N shares, it will still have N shares after app #2 is
deployed (and app #2 will also have N shares, given it has the same amount
of memory). This ties in with Matthew's point that there's no overall limit
to the number of shares.

I'm afraid I'm not quite sure what the absolute share values are and how
they're calculated relative to the memory amount.

On 30 July 2015 at 18:10, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The old vcap-dev mailing list had a number of exchanges around this topic
that you might want to look at.

The basic gist is that linux gives processes that are not associated with
a cgroup a cpu share of 1024. That means that the code that runs the DEA
and all of the linux daemons that make things go will get that share.

When applications are placed on a DEA, the containers they run in are
associated with a cpu share that is proportional to the amount of memory
requested. If you request a lot of memory per app instance, you'll have a
high cpu share; if you request a little memory per app instance, you'll
have a low cpu share.

The cpu share values associated with the container cgroups will never be
allowed to exceed 1024 (to prevent applications from adversely impacting
the DEA processes).

These cpu share values really only start to impact things when there's
competition for the cpu. When that happens, processes in a cgroup that is
associated with higher shares will get more cpu than those with lower
shares.

There is no "limit" to the number of shares - they're treated as relative
values when the scheduler needs to make a choice. The goal is that, given
two processes A and B, if process A has a share weight that is twice that
of process B and both processes are cpu bound, process A will get twice as
many shares of the cpu as process A.

For a more complete understanding, you should read the documentation in
the linux tree for the scheduler.

On Tue, Jul 28, 2015 at 8:11 PM, John Wong <gokoproject(a)gmail.com> wrote:

I am reading
https://docs.cloudfoundry.org/concepts/architecture/warden.html#cpu and
it said:

If B is idle, A may receive up to all the CPU. Shares per cgroup range
from 2 to 1024, with 1024 the default. Both Diego apps and DEA apps scale
the number of allocated shares linearly with the amount of memory, with an
app instance requesting 8G of memory getting the upper limit of 1024
shares. Diego also guarantees a minimum of 10 shares per app instance.

So 1024 is the default share every app get by default?

Say I start with an empty DEA.


APP #1: 1G shared = 1024?

APP #2 added. 1G shared =? what happen to APP #1?

APP #2 added: 512MB shared =? What happened to APP #1 & APP 2?

APP #3 added: 8GB, now what happened?


I am all assuming their usage is nearly idle. What is the total number of
share for a N-core DEA? Also are the shares dynamic? In the mean time I
will try to understand how CPU usage is shared in cgroup from other
resource.


Thanks.


John

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: App autosleep support

Guillaume Berche
 

Thanks Gwenn and James for your feedback. Responses inline below

On Fri, Jul 31, 2015 at 7:57 AM, James Bayer wrote:


you should consider rescheduling when moving out of the dormant state
(which may take awhile to send the container image to a new host), then you
have to account for resource reservations on the Cells anyway in case they
all wake up. one possibility is the common case to have the container image
pre-staged on a host and the Cell typically would have enough resources
available. in the case where it doesn't, then you reschedule and hold the
requests (up to a max # of requests for that app) longer. has some
interesting potential for DOS if not constrained.
I would think that autosleep and auto-wakeup only make sense for apps that
can tolerate their traffic to be heldup for a while (i.e. time to schedule
the container image on a host), or alternatively tolerage their traffic to
transiently return 504 status code when wakingup. Apps that require better
availability and performance would be OK to pay for 2 permanent instances.


the use of a route-service for implementation is an interesting idea, but
it does mean that every request for the app needs to go through a route
service even when the app is not sleeping, so i could also see other
alternative designs that stay out of the request path unless the app is
dormant. maybe that's something the system could do (after inactivity
period bind the app to a route-service) and when leaving the dormant state,
unbind the app from the route service.
great idea, thanks! Implies the autosleep service would use some other way
to capture the incoming traffic signal (e.g. consume metron gorouter
metrics for the app), as to measure inactivity.

it's probably most important to define "the what and why" of this feature
first, and then we can ask the routing eng team if they have ideas on how
to implement or if it makes sense as existing points of extension like a
service and the in-progress route service.
Sounds good. Is the autosleep proposal document a good place to start this
"what and why" definition ? Should I made the document writeable by anyone
or just responding to incoming write access request sufficient ?

Guillaume.



On Thu, Jul 30, 2015 at 5:58 PM, Gwenn Etourneau wrote:

For the autosleep feature why not but again only for non-prod application.

In my previous company, for DEV environment we stop application which
have been not updated since one month except some exception.
We considered that DEV is for active development.
Was just a batch script looking in the CCDB and calling cf-cli to stop
apps.






On Thu, Jul 30, 2015 at 7:46 PM, Guillaume Berche wrote:

Hi,

I wonder if there are plans to implement an auto-sleep behavior in
cloudfoundry, in which inactive apps would be automatically stopped after a
max inactivity threshold, and automatically restart upon arrival of traffic
on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of
our non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such
feature or would be interested in collaborating on an opensource
implementation.

I drafted some specs for a java-based implementation we're planning to
work on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: How long will events be kept?

Gwenn Etourneau
 

Event are purged based on some value put on your manifest :

cc.app_events.cutoff_age_in_days:
description: "How old an app event should stay in cloud controller
database before being cleaned up"
default: 31
cc.app_usage_events.cutoff_age_in_days:
description: "How old an app usage event should stay in cloud
controller database before being cleaned up"
default: 31
cc.audit_events.cutoff_age_in_days:
description: "How old an audit event should stay in cloud controller
database before being cleaned up"
default: 31
cc.failed_jobs.cutoff_age_in_days:
description: "How old a failed job should stay in cloud controller
database before being cleaned up"
default: 31

On Fri, Jul 31, 2015 at 3:54 PM, Guangcai Wang <guangcai.wang(a)gmail.com>
wrote:

Hi all,

Recently, I am playing with Event API[1]. I am wondering if the events
will be kept persistent for ever or will be purged automatically based on
some policy. Who can share some details?

Meanwhile, I found there is no event audit.app.stop. It was
audit.app.update when I stopped the app. Is it a code bug or documentation
bug?
{
"metadata": {
"guid": "ff81faa1-ce42-415d-a482-defc27524ef4",
"url": "/v2/events/ff81faa1-ce42-415d-a482-defc27524ef4",
"created_at": "2015-07-31T05:27:18Z",
"updated_at": null
},
"entity": {
"type": "audit.app.update",
"actor": "7d85d3d1-9d23-4ba4-8908-7f634f37d0d4",
"actor_type": "user",
"actor_name": "admin",
"actee": "b4953111-9913-4fbf-835a-a6f618c6a59d",
"actee_type": "app",
"actee_name": "simple-java",
"timestamp": "2015-07-31T05:27:18Z",
"metadata": {
"request": {
"state": "STOPPED"
}
},
"space_guid": "d9e4eb09-6b31-401b-87ea-2305364f7a1a",
"organization_guid": "79f25032-0f56-4c7c-86cc-d5c6a67ec300"
}
},




[1] http://apidocs.cloudfoundry.org/214/events/list_app_update_events.html


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: UAA: How to set client_credentials token grant type to not expire

Paul Bakare
 

Filip,

Here's my client config:
useraccount
scope: clients.read oauth.approvals openid password.write tokens.read
tokens.write uaa.admin
resource_ids: none
authorized_grant_types: authorization_code client_credentials password
refresh_token
authorities: scim.read scim.userids uaa.admin uaa.resource clients.read
scim.write cloud_controller.write scim.me clients.secret password.write
clients.write openid cloud_controller.read oauth.approvals
access_token_validity: 315360000
autoapprove: true

Gotten from `uaac clients`

I really do not know what else I might be doing wrongly.

Does `test_Token_Expiry_Time()` also cover for client_credentials grant
type? I tried running the test with
`./gradlew test
-Dtest.single=org/cloudfoundry/identity/uaa/mock/token/TokenMvcMockTests`
and placed debuggers in order to view the generated expiration time.
Nothing was printed in the test results.

On Wed, Jul 29, 2015 at 6:11 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276

most likely your client does not have the access token validity setup
correctly. See the test case I posted that validates my statements

https://github.com/cloudfoundry/uaa/commit/f0c8ba99cf37855fec54b74c07ce19613c51d7e9#diff-f7a9f1a69eec2ce4278914f342d8a160R883


On Wed, Jul 29, 2015 at 9:57 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Good. But my apologies. Assume:

creation time = 1438184877
access token validity (set by me) = 315360000

exp is expected to be 1753544877 when decoded. Unfortunately, this test
fails, as exp reads 1438228276

On Wed, Jul 29, 2015 at 5:43 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?

It's a little bit different.

access_token_validity is how long the token is valid for from the time
of creation. thus we can derive

exp (expiration time) = token creation time + access token validity

you don't get to set the expiration time, since that doesn't make sense
as the clock keeps ticking forward.

in your case, having access token validity be 10 years, achieves exactly
what you want

Filip


On Wed, Jul 29, 2015 at 9:36 AM, Kayode Odeyemi <dreyemi(a)gmail.com>
wrote:

Thanks again Filip.

However, here's what I mean,

If I set the access_token_validity to 315569260, I'm expecting the
token when decoded to read exp: 315569260. If this is not, then is it
possible to set the token expiry time?

line 906 sets the value to 1438209609 when the token is decoded and I
believe that's what the check_token service also checks.
expirationTime*1000l occurs after the token has been decoded (whose exp
value is set to 1438209609)

Now the question is why do you have to do expirationTime*1000l since
the token when decoded originally set's this value to 1438209609
(without * 1000l)

Except I'm completely getting this all wrong?

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


How long will events be kept?

iamflying
 

Hi all,

Recently, I am playing with Event API[1]. I am wondering if the events will
be kept persistent for ever or will be purged automatically based on some
policy. Who can share some details?

Meanwhile, I found there is no event audit.app.stop. It was
audit.app.update when I stopped the app. Is it a code bug or documentation
bug?
{
"metadata": {
"guid": "ff81faa1-ce42-415d-a482-defc27524ef4",
"url": "/v2/events/ff81faa1-ce42-415d-a482-defc27524ef4",
"created_at": "2015-07-31T05:27:18Z",
"updated_at": null
},
"entity": {
"type": "audit.app.update",
"actor": "7d85d3d1-9d23-4ba4-8908-7f634f37d0d4",
"actor_type": "user",
"actor_name": "admin",
"actee": "b4953111-9913-4fbf-835a-a6f618c6a59d",
"actee_type": "app",
"actee_name": "simple-java",
"timestamp": "2015-07-31T05:27:18Z",
"metadata": {
"request": {
"state": "STOPPED"
}
},
"space_guid": "d9e4eb09-6b31-401b-87ea-2305364f7a1a",
"organization_guid": "79f25032-0f56-4c7c-86cc-d5c6a67ec300"
}
},




[1] http://apidocs.cloudfoundry.org/214/events/list_app_update_events.html


Re: Notifications on ORG, SPACE and USER modifications

Pablo Alonso Rodriguez <palonsoro@...>
 

For us, the main use case would also be security auditing, like for Mike.
We do not know yet what tool should receive them, but directly sending them
to a syslog endpoint (without having to pull them) may be a good
alternative (at least, among a bigger set of options).

Secondarily, it might also be interesting for billing.

2015-07-30 0:37 GMT+02:00 Piotr Przybylski <piotrp(a)us.ibm.com>:

We have several use cases
- in time event processing for usage, with notification instead of polling
we'll be able to keep up better, getting closer to real time for metering,
and thus rating and billing
- timely display of the new system objects like spaces or organizations,
being notified about new objects, avoids retrieving all objects and
comparing which is already known
- detecting and signaling entity field or property changes, for example
name changes, which can require polling and comparison
These in turn would allow better support uses like
- console or UI reactive to entity changes
- activity dashboards
- analytics

Piotr


[image: Inactive hide details for Mike Youngstrom ---07/29/2015 08:54:59
AM---For us the main use case is security auditing to keep a l]Mike
Youngstrom ---07/29/2015 08:54:59 AM---For us the main use case is security
auditing to keep a long term record of who has done anything.



From:


Mike Youngstrom <youngm(a)gmail.com>

To:


"Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>

Date:


07/29/2015 08:54 AM

Subject:


Re: [cf-dev] Notifications on ORG, SPACE and USER modifications

Sent by:


cf-dev-bounces(a)lists.cloudfoundry.org
------------------------------



For us the main use case is security auditing to keep a long term record
of who has done anything. In the case of our Security team rather than use
CF events directly they preferred to have events forwarded to Security
Analytics. Today we pull events then forward the details to Security
Analytics via a syslog endpoint.

Mike

[0]
*http://www.emc.com/security/security-analytics/security-analytics.htm*
<http://www.emc.com/security/security-analytics/security-analytics.htm>

On Tue, Jul 28, 2015 at 11:26 PM, Dieu Cao <*dcao(a)pivotal.io*
<dcao(a)pivotal.io>> wrote:

Hi all interested in notifications on modification of resources,

It would be helpful for me in framing the "what" and the "why" of this
feature if you could also describe your specific use cases and pain points
on why you would want notifications on modifications and also which
resources you particularly care about.
Is it for real time updates on a dashboard? For consumption for
billing purposes? For triggering provisioning/deprovisioning of resources?

-Dieu

On Tue, Jul 28, 2015 at 11:05 AM, Jean-Sebastien Delfino <
*jsdelfino(a)gmail.com* <jsdelfino(a)gmail.com>> wrote:
I’m going to need something like this too for the CF Abacus service
metering project, as I’d like to track the lifecycle of orgs, users, etc to
match their history with the usage data reported for them.

Here’s a straw man description of what I had in mind:

- For Abacus, I’d need a Lossless API. Usage metering eventually
translates to billing and money, you don’t want to lose that :)

- An extension or variant of the current CF /v2/events API
supporting users, orgs, app usage etc, as even with a notification API I’ll
still need to do GETs sometimes.

- 304 responses with etags on these GETs (as suggested earlier in
the thread [1]) would be good.

- A Webhook style notification API where I could register interest
in a selection of events with a callback URL, and get these events POSTed
back to me at that URL, similar to what Github and many others do with
Webhooks.

- On top of Webhooks, it’d be nice to have a form of streaming
(either down to the client like the Firehose does or in the other direction
up to the Webhook callback URL), but I'm not sure if we’ll need that in the
project right away.

- We’d obviously need some form of security, maybe use my user
token to register for events on entities that I have access to?

- I’m also curious about the group’s thoughts on queueing and
back-pressure when events get generated faster that they can be consumed
for example. There was a mention of some message queuing earlier [2]. That
would make sense to me (although IMO it’d be good if the underlying MQ
didn’t shine through the API). What did you have in mind for this?

I guess there are quite a few things to figure out here! I’ll be
happy to collaborate with the community on these discussions.

Thoughts?

[1]
*http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p842.html*
<http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p842.html>
[2]
*http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p834.html*
<http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tp827p834.html>

- Jean-Sebastien


On Fri, Jul 24, 2015 at 9:59 PM, Matt Cowger <*matt(a)cowger.us*
<matt(a)cowger.us>> wrote:
I think ETags is reasonable thought as well.

On Thu, Jul 23, 2015 at 4:39 PM, Benjamin Black <
*bblack(a)pivotal.io* <bblack(a)pivotal.io>> wrote:
ETags and a 304 response are specifically intended for that
purpose. I'd recommend that over relying on Last-Modified.


b

On Thu, Jul 23, 2015 at 12:34 AM, Koper, Dies <
*diesk(a)fast.au.fujitsu.com* <diesk(a)fast.au.fujitsu.com>>
wrote:
Or setting the Last-Modified HTTP response header
accordingly, and allow clients to use HTTP caching mechanisms
(Last-Modified, etc.) to get quick empty responses with the current APIs if
no changes have been made? (Or maybe this is already working so – haven’t
checked).



Regards,

Dies Koper



*From:* *cf-dev-bounces(a)lists.cloudfoundry.org*
<cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:
*cf-dev-bounces(a)lists.cloudfoundry.org*
<cf-dev-bounces(a)lists.cloudfoundry.org>] *On Behalf Of *Matt
Cowger
* Sent:* Thursday, July 23, 2015 4:45 PM
* To:* Discussions about Cloud Foundry projects and the system overall.

*Subject:* Re: [cf-dev] Notifications on ORG, SPACE and
USER modifications



I've wanted something similar as well.



On a related note, having a CC API 'serial' number (for
each object in CC - apps, spaces, etc) that increments on every change
relevant to that object would be of value for detecting if something has
changed.



On Thu, Jul 23, 2015 at 3:27 PM, Dieu Cao <
*dcao(a)pivotal.io* <dcao(a)pivotal.io>> wrote:

There are a few different approaches to this and different
concerns that are possible.

The requests I've seen have been around wanting to be able
to subscribe to and filter the various events that cc currently generates
so that other behavior could be triggered.

We currently have events, app usage events, and service
usage events.

Is it acceptable for the notifications to be lossy?
Depends on the use case but If so, then the firehose may be an acceptable
approach.



The CAPI team is currently focusing on other work in the
near term, such as the v3 API and private brokers, but would be happy to
collaborate on a proposal.





On Wed, Jul 22, 2015 at 2:05 PM, Juan Pablo Genovese <
*juanpgenovese(a)gmail.com* <juanpgenovese(a)gmail.com>> wrote:

My take:



CC should have callbacks on for each model create, update
and delete methods. Those callbacks will send a message to an MQ, which you
can subscribe to consume those messages.

This can be expanded to pretty much every event we need to
track.

What do you think?



JP



2015-07-22 17:30 GMT-03:00 Matthias X Hub <
*matthias.hub(a)de.ibm.com* <matthias.hub(a)de.ibm.com>>:

Hi,

we (=IBM) are also having the need and are currently
investigating how to solve this. We plan to work on a proposal to discuss
this further with the cf community. I'll keep you updated on that.


Regards,
Matthias



From: Mike Youngstrom <*youngm(a)gmail.com*
<youngm(a)gmail.com>>
To: "Discussions about Cloud Foundry projects and
the system overall." <*cf-dev(a)lists.cloudfoundry.org*
<cf-dev(a)lists.cloudfoundry.org>>
Date: 22.07.2015 20:57
Subject: Re: [cf-dev] Notifications on ORG, SPACE
and USER modifications
Sent by: *cf-dev-bounces(a)lists.cloudfoundry.org*
<cf-dev-bounces(a)lists.cloudfoundry.org>

------------------------------




We have the same need. Today we are polling the CC.

It would be nice for us also if we could get CC event
notifications via something like the firehose.

Mike

On Wed, Jul 22, 2015 at 10:23 AM, Juan Pablo Genovese <
*juanpgenovese(a)gmail.com* <juanpgenovese(a)gmail.com>>
wrote:
I mean, I know you can list those events thru the API, but
I want something that will react on an event instead of having to be
constantly polling for them.

2015-07-22 13:18 GMT-03:00 Juan Pablo Genovese <
*juanpgenovese(a)gmail.com* <juanpgenovese(a)gmail.com>>:
Sree,

thanks! Any pointers on how can I hook up to these audit
events?

Thank you!

2015-07-22 13:12 GMT-03:00 Sree Tummidi <
*stummidi(a)pivotal.io* <stummidi(a)pivotal.io>>:
I believe there are audit events generated for all these
actions which can be captured and forwarded to an SIEM solution like splunk

Thanks,
Sree

Sent from my iPhone

On Jul 22, 2015, at 8:54 AM, Juan Pablo Genovese <
*juanpgenovese(a)gmail.com* <juanpgenovese(a)gmail.com>> wrote:

Guys,

I need to somehow hook up into the Cloud Controller (CC)
to capture ORG, SPACE and USER deletion, insertion and update.

So far, I considered some approaches, such as forking the
CC (the least favorite) and modifying the code with some hooks, tapping
into Nginx to capture the requests, and using triggers in the database to
capture each event and send the necessary info to a service.

What do you think?
Any other idea you might have?

Thanks!

--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------

*http://www.jpgenovese.com* <http://www.jpgenovese.com/>
_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>

_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>




--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
*http://www.jpgenovese.com* <http://www.jpgenovese.com/>



--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
*http://www.jpgenovese.com* <http://www.jpgenovese.com/>


_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>

_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>


_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>




--

Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------

*http://www.jpgenovese.com* <http://www.jpgenovese.com/>


_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>




_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>




--

-- Matt

_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>



_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>



--
-- Matt

_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>



--
Jean-Sebastien

Sent from my DynaTAC 8000x

_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>



_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: SSH access to CF app instances on Diego

Gwenn Etourneau
 

Oh I think you are right James ..
Do we have a google docs discussing around that ?

On Fri, Jul 31, 2015 at 2:39 PM, James Bayer <jbayer(a)pivotal.io> wrote:

gwenn, i suspect guillaume is referencing the platform policies around ssh
and container lifecycle which has not had more discussion that i'm aware
of. i think eric has received some additional feedback from some people,
but i have not seen what it is either or an outline of how the defaults and
configuration options will be exposed.

On Thu, Jul 30, 2015 at 6:01 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Guillaume,

Not sure is related but the ssh have been already implemented and is
available on diego and cf-release.


On Thu, Jul 30, 2015 at 10:35 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Eric,

The CAB minutes [1] mentionned you were still looking for feedback from
the community on the policy for altered instances, but this thread seems
silent for a while.

Not sure you had seen my email and suggestion below for a way to
quarantine the altered instances (beyond the per-space restart policy
configuration). Such quarantine request might be a good place to include
option to ask for the quarantine instances to be excluded from gorouter
traffic.

[1]
http://www.activestate.com/blog/2015/07/cloud-foundry-advisory-board-meeting-2015-july

Regards,

Guillaume.

On Fri, Jul 3, 2015 at 3:56 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

please find my feedback to this thread

*short version:*
1- need preserve good CF experience with HTTP only (direct SSH flow is
still blocked and a pain in many organisations) => +1 to preserve "cf
files" or fine tune diego plug to have ssh over HTTP to work out of the box
2- default "recycle tainted containers by default" policy seems good to
me
3- needs to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )
4- development use-cases need to be better supported (dev/prod parity)
not sure ssh/scp is the right path though

*long version:*

*1- cf files and ssh over HTTP*

As previously mentionned into [1], CF exposing apis over HTTP api made
a great job to be easily consummed through HTTP proxies that some companies
still use, making CF experience seemless to consumme public paas, or
private paas among corporate entities. It seems important to me to preserve
good CF experience with HTTP only.

If SSH interactive access, scp and port forwarding become the
mainstream solution to operate and troubleshoot apps (supporting "cf
files", replacement for the previous DEBUG and CONSOLE ports), it will be
useful for users behind such firewalls to be able to configure diego ssh
plugin to use HTTP/SOCKS proxies to reach public CF instances. As the diego
ssh cli plugin supports using the regular local host ssh binaries, this may
potentially be done by tweaking the .ssh config file to add flags
associated to host ssh.${domain} to go through proxies (possibly double
tunnels as described into [2]). However, for new users in such network
context, especially on windows operating system, the set up work before
using a CF public instance starts to add up?

*2- default "recycle tainted containers by default" seems good to me*

Given that apps deployed on CF comply to 12 factor apps, there instance
may be restarted at anytime (e.g. during a CF new release deployment or
stemcell upgrade). So the default policy "recycle tainted containers by
default" is not a surprise.

*3- need to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )*

There are some specific use-cases where the "recycle tainted containers
by default" policy would be problematic when running applications in
production:

An application instance is malfunctionning (e.g. hanging) and an
interactive debugging is necessary. The app-ops ssh into the container and
starts taking some diagnostic steps (e.g sending kill -SIGTERM signals to
take thread dumps, or locally changes log levels).

If ever the ssh connection breaks/timeout, the "recycle tainted
containers by default, preventing the current diagnostc to complete.

Another similar use case: a production application is suspected to be
compromised by an attacker. App-ops need to capture evidences and
understand better how the abuse was done. There isn't enough information in
streamed logs, and there is a need to get into the container to inspect the
ephemeral FS and the processes and memory. This may require more than one
simultanenous SSH connection, and may span on multiple hours

In both use-cases above, while the application is 12 factor compliant
and the "recycle tainted containers by default" policy would be opted in on
the corresponding space, there would be a need to transiently turn the mode
off.

In term of user experience, this may appear as an explicit user request
to "quarantine" the tainted app instances (or the whoe app) so that CF does
not attempt to restart them. Or it may appear as the google app engine
"lock/unlock"

a call to a new "unlock" command to a CF app instance would be
necessary to get SSH access to it. CF then considers this instance as
"tained"/untrusted, as it may have deviated from the pushed content, and
does not act to it anymore (i.e. does not monitor its bound $PORT or root
process exit, which may be handy to diagnose it as wish). When the "lock"
command is requested on this instance, Cf destroys this tainted instance,
and recreates a fresh new "trusted" one.

*4- development use-cases need to be better supported (dev/prod parity)
not sure ssh/scp is the right path though*

I agree with James Myers that development use-cases should be better
supported.

First, CF should strive to support dev-prod parity [4]. However
currently, there is not anymore a version of CF that a developper can run
on his laptop (e.g. when doing offline development during commute) that
would behave like prod and embed buildpacks. There used to have "CF on a
single VM". Heroku or GAE have emulators. Cloud rocker [5] is close, but it
still takes 10s or more to have changes made on the app be reflected into a
running app.

There are some legitimate use cases during development for modifying
sources of the application and have those changes be taken in effect
immediately. Lots of app development framework supports those development
modes (even those that promote test-driven practices), and getting a fast
feedback is important. Having dev-prod parity means supporting these use
cases while preserving prod behavior (having the VCAP_SERVICES and
VCAP_APPLICATION and the buildpack processing applied on the same stack
(cflinux2)). Being able to run offline would be even better.

I however believe that providing SSH/SCP access to change the file
system to a running app instance may not be the appropriate response, given
the FS and the app instance is still ephemeral. Who would want to modify
files that could be lost at any time (e.g. a stemcell upgrade ) ?

I'd rather see value in further exploring the ideas layed out by James
Bayer into [5] e.g. as a form of a git repo populated with the
/home/vcap/app subdir, that developers could clone, push to, and have the
instance epheremal FS updated with pushed changes.

This may be combined with a cloudrocker mechanism as to work with a
fully offline mode when this is required.

[1]
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/OavSBIhU_xQ/wJrT08iHfJ8J
[2] http://proxytunnel.sourceforge.net/paper.php
[3]
https://cloud.google.com/appengine/docs/managed-vms/host-env#changing_management
[4] http://12factor.net/dev-prod-parity
[5]
https://docs.google.com/document/d/1_C3OWS6giWx4JL_IL9YLA6jcppyQLVD-YjR0GeA8Z0s/edit#heading=h.toypuu5pxh65



On Thu, Jul 2, 2015 at 10:18 PM, James Myers <jmyers(a)pivotal.io> wrote:

I have to agree with Matt on this one. I feel that the recycling of
containers is a very anti-developer default. When you approach Cloud
Foundry from the perspective of running production applications the recycle
policy makes complete sense. However, I feel that this misses out on one of
the massive benefits/use cases of Cloud Foundry, what it offers to the
development process.

From a security stand point, if you can ssh into a container, it means
you have write access to the application in CloudFoundry. Thus you can
already push new bits/change the application in question. All of the
"papertrail" functionality around pushing/changing applications exists for
SSH as well (we record events, output log lines, make it visible to users
that action was taken on the application), and thus concerned operators
would be able to determine if someone modifying the application in question.

Therefore I'm lost on how this is truly the most secure default. If we
are really going by the idea that all defaults should be the most secure,
ssh should be disabled by default.

As a developer, I can see many times in which I would want to be able
to ssh into my container and change my application as part of a
troubleshooting process. Using BOSH as an example, CF Devs constantly ssh
into VMs and change the processes running on them in order to facilitate
development. BOSH does not reap the VM and redeploy a new instance when you
have closed the SSH session. Once again this is largely due to the fact
that if you have SSH access, you can already perform the necessary actions
to change the application through different means.

Another huge hindrance to development, is that the recycling policy is
controlled by administrators. It is not something that normal users can
control, even though we allow the granularity of enabling/disabling SSH
completely to the end user. This seems counterintuitive.

I feel that a better solution would be to provide the user with some
knowledge of which instances may be tainted, and then allowing them to opt
into a policy which will reap tainted containers. This provides users with
clear insight that their application instance may be a snowflake (and that
they may want to take action), while also allowing normal behavior with
regards to SSH access to containers.

To summarize, by enabling the recycling policy by default we not only
produce extremely unusual behavior / workflows for developers, we are also
minimizing the developer-friendliness of CF in general. This mixed with the
fact that as a user I cannot even control this policy, leads me to believe
that as a default recycling should be turned off as it provides the most
cohesive and friendly user experience.

On Mon, Jun 29, 2015 at 9:14 AM, John Wong <gokoproject(a)gmail.com>
wrote:

after executing a command, concluding an interactive session, or
copying a file into an instance, that instance will be restarted.

How does it monitor the behavior? Is there a list of commands
whitelisted? I am curious because I am trying to find out what the
whitelist contain. Also is it at the end of the bosh ssh APP_NAME session?
What if two users are there simultaneously?

Thanks.

On Mon, Jun 29, 2015 at 5:49 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

I think with the CLI we could add clarifying messaging when using
ssh what the current policy around recycling is.
Eric, what do you think about calling it the "recycling" policy,
enabled by default? =D

-Dieu


On Sat, Jun 27, 2015 at 3:42 AM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

Depends on your role and where your app is in the deployment
pipeline. Most of the scenarios I envisioned were for the tail end of
development where you need to poke around to debug and figure out those
last few problems.

For example, Ryan Morgan was saying that the Cloud Foundry plugin
for eclipse is going to be using the ssh support in diego to enable debug
of application instances in the context of a buildpack deployed app. This
is aligned with other requirements I've heard from people working on dev
tools.

As apps reach production, I would hope that interactive ssh is
disabled entirely on the prod space leaving only scp in source mode as an
option (something the proxy can do).

Between dev and prod, there's a spectrum, but in general, I either
expect access to be enabled or disabled - not enabled with a suicidal
tendency.

On Thu, Jun 25, 2015 at 10:53 PM, Benjamin Black <bblack(a)pivotal.io
wrote:
matt,

could you elaborate a bit on what you believe ssh access to
instances is for?


b


On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

My concern is the default behavior.

When I first prototyped this support in February, I never
expected that merely accessing a container would cause it to be terminated.
As we can see from Jan's response, it's completely unexpected; many others
have the same reaction.

I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.

I honestly believe that if we were talking about applying this
behavior to `bosh ssh` and `bosh scp`, few would even consider running in a
'kill on taint mode' because of how useful it is. We should learn from that.

If this behavior becomes the default, I think our platform will
be seen as moving from opinionated to parochial. That would be unfortunate.


On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io>
wrote:

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <
jand(a)activestate.com> wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io>
wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that
instance will
be restarted.
What is the purpose of being able to copy a file into an
instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: App autosleep support

James Bayer
 

this feature request has come up occasionally, but rarely. this type of
feature is usually the most applicable to service providers with a free or
very low cost tier, where this can make a substantial difference in
increasing density.

you should consider rescheduling when moving out of the dormant state
(which may take awhile to send the container image to a new host), then you
have to account for resource reservations on the Cells anyway in case they
all wake up. one possibility is the common case to have the container image
pre-staged on a host and the Cell typically would have enough resources
available. in the case where it doesn't, then you reschedule and hold the
requests (up to a max # of requests for that app) longer. has some
interesting potential for DOS if not constrained.

the use of a route-service for implementation is an interesting idea, but
it does mean that every request for the app needs to go through a route
service even when the app is not sleeping, so i could also see other
alternative designs that stay out of the request path unless the app is
dormant. maybe that's something the system could do (after inactivity
period bind the app to a route-service) and when leaving the dormant state,
unbind the app from the route service.

it's probably most important to define "the what and why" of this feature
first, and then we can ask the routing eng team if they have ideas on how
to implement or if it makes sense as existing points of extension like a
service and the in-progress route service.

On Thu, Jul 30, 2015 at 5:58 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

For the autosleep feature why not but again only for non-prod application.

In my previous company, for DEV environment we stop application which have
been not updated since one month except some exception.
We considered that DEV is for active development.
Was just a batch script looking in the CCDB and calling cf-cli to stop
apps.






On Thu, Jul 30, 2015 at 7:46 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I wonder if there are plans to implement an auto-sleep behavior in
cloudfoundry, in which inactive apps would be automatically stopped after a
max inactivity threshold, and automatically restart upon arrival of traffic
on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of
our non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such
feature or would be interested in collaborating on an opensource
implementation.

I drafted some specs for a java-based implementation we're planning to
work on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


Re: SSH access to CF app instances on Diego

James Bayer
 

gwenn, i suspect guillaume is referencing the platform policies around ssh
and container lifecycle which has not had more discussion that i'm aware
of. i think eric has received some additional feedback from some people,
but i have not seen what it is either or an outline of how the defaults and
configuration options will be exposed.

On Thu, Jul 30, 2015 at 6:01 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Guillaume,

Not sure is related but the ssh have been already implemented and is
available on diego and cf-release.


On Thu, Jul 30, 2015 at 10:35 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Eric,

The CAB minutes [1] mentionned you were still looking for feedback from
the community on the policy for altered instances, but this thread seems
silent for a while.

Not sure you had seen my email and suggestion below for a way to
quarantine the altered instances (beyond the per-space restart policy
configuration). Such quarantine request might be a good place to include
option to ask for the quarantine instances to be excluded from gorouter
traffic.

[1]
http://www.activestate.com/blog/2015/07/cloud-foundry-advisory-board-meeting-2015-july

Regards,

Guillaume.

On Fri, Jul 3, 2015 at 3:56 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

please find my feedback to this thread

*short version:*
1- need preserve good CF experience with HTTP only (direct SSH flow is
still blocked and a pain in many organisations) => +1 to preserve "cf
files" or fine tune diego plug to have ssh over HTTP to work out of the box
2- default "recycle tainted containers by default" policy seems good to
me
3- needs to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )
4- development use-cases need to be better supported (dev/prod parity)
not sure ssh/scp is the right path though

*long version:*

*1- cf files and ssh over HTTP*

As previously mentionned into [1], CF exposing apis over HTTP api made a
great job to be easily consummed through HTTP proxies that some companies
still use, making CF experience seemless to consumme public paas, or
private paas among corporate entities. It seems important to me to preserve
good CF experience with HTTP only.

If SSH interactive access, scp and port forwarding become the mainstream
solution to operate and troubleshoot apps (supporting "cf files",
replacement for the previous DEBUG and CONSOLE ports), it will be useful
for users behind such firewalls to be able to configure diego ssh plugin to
use HTTP/SOCKS proxies to reach public CF instances. As the diego ssh cli
plugin supports using the regular local host ssh binaries, this may
potentially be done by tweaking the .ssh config file to add flags
associated to host ssh.${domain} to go through proxies (possibly double
tunnels as described into [2]). However, for new users in such network
context, especially on windows operating system, the set up work before
using a CF public instance starts to add up?

*2- default "recycle tainted containers by default" seems good to me*

Given that apps deployed on CF comply to 12 factor apps, there instance
may be restarted at anytime (e.g. during a CF new release deployment or
stemcell upgrade). So the default policy "recycle tainted containers by
default" is not a surprise.

*3- need to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )*

There are some specific use-cases where the "recycle tainted containers
by default" policy would be problematic when running applications in
production:

An application instance is malfunctionning (e.g. hanging) and an
interactive debugging is necessary. The app-ops ssh into the container and
starts taking some diagnostic steps (e.g sending kill -SIGTERM signals to
take thread dumps, or locally changes log levels).

If ever the ssh connection breaks/timeout, the "recycle tainted
containers by default, preventing the current diagnostc to complete.

Another similar use case: a production application is suspected to be
compromised by an attacker. App-ops need to capture evidences and
understand better how the abuse was done. There isn't enough information in
streamed logs, and there is a need to get into the container to inspect the
ephemeral FS and the processes and memory. This may require more than one
simultanenous SSH connection, and may span on multiple hours

In both use-cases above, while the application is 12 factor compliant
and the "recycle tainted containers by default" policy would be opted in on
the corresponding space, there would be a need to transiently turn the mode
off.

In term of user experience, this may appear as an explicit user request
to "quarantine" the tainted app instances (or the whoe app) so that CF does
not attempt to restart them. Or it may appear as the google app engine
"lock/unlock"

a call to a new "unlock" command to a CF app instance would be necessary
to get SSH access to it. CF then considers this instance as
"tained"/untrusted, as it may have deviated from the pushed content, and
does not act to it anymore (i.e. does not monitor its bound $PORT or root
process exit, which may be handy to diagnose it as wish). When the "lock"
command is requested on this instance, Cf destroys this tainted instance,
and recreates a fresh new "trusted" one.

*4- development use-cases need to be better supported (dev/prod parity)
not sure ssh/scp is the right path though*

I agree with James Myers that development use-cases should be better
supported.

First, CF should strive to support dev-prod parity [4]. However
currently, there is not anymore a version of CF that a developper can run
on his laptop (e.g. when doing offline development during commute) that
would behave like prod and embed buildpacks. There used to have "CF on a
single VM". Heroku or GAE have emulators. Cloud rocker [5] is close, but it
still takes 10s or more to have changes made on the app be reflected into a
running app.

There are some legitimate use cases during development for modifying
sources of the application and have those changes be taken in effect
immediately. Lots of app development framework supports those development
modes (even those that promote test-driven practices), and getting a fast
feedback is important. Having dev-prod parity means supporting these use
cases while preserving prod behavior (having the VCAP_SERVICES and
VCAP_APPLICATION and the buildpack processing applied on the same stack
(cflinux2)). Being able to run offline would be even better.

I however believe that providing SSH/SCP access to change the file
system to a running app instance may not be the appropriate response, given
the FS and the app instance is still ephemeral. Who would want to modify
files that could be lost at any time (e.g. a stemcell upgrade ) ?

I'd rather see value in further exploring the ideas layed out by James
Bayer into [5] e.g. as a form of a git repo populated with the
/home/vcap/app subdir, that developers could clone, push to, and have the
instance epheremal FS updated with pushed changes.

This may be combined with a cloudrocker mechanism as to work with a
fully offline mode when this is required.

[1]
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/OavSBIhU_xQ/wJrT08iHfJ8J
[2] http://proxytunnel.sourceforge.net/paper.php
[3]
https://cloud.google.com/appengine/docs/managed-vms/host-env#changing_management
[4] http://12factor.net/dev-prod-parity
[5]
https://docs.google.com/document/d/1_C3OWS6giWx4JL_IL9YLA6jcppyQLVD-YjR0GeA8Z0s/edit#heading=h.toypuu5pxh65



On Thu, Jul 2, 2015 at 10:18 PM, James Myers <jmyers(a)pivotal.io> wrote:

I have to agree with Matt on this one. I feel that the recycling of
containers is a very anti-developer default. When you approach Cloud
Foundry from the perspective of running production applications the recycle
policy makes complete sense. However, I feel that this misses out on one of
the massive benefits/use cases of Cloud Foundry, what it offers to the
development process.

From a security stand point, if you can ssh into a container, it means
you have write access to the application in CloudFoundry. Thus you can
already push new bits/change the application in question. All of the
"papertrail" functionality around pushing/changing applications exists for
SSH as well (we record events, output log lines, make it visible to users
that action was taken on the application), and thus concerned operators
would be able to determine if someone modifying the application in question.

Therefore I'm lost on how this is truly the most secure default. If we
are really going by the idea that all defaults should be the most secure,
ssh should be disabled by default.

As a developer, I can see many times in which I would want to be able
to ssh into my container and change my application as part of a
troubleshooting process. Using BOSH as an example, CF Devs constantly ssh
into VMs and change the processes running on them in order to facilitate
development. BOSH does not reap the VM and redeploy a new instance when you
have closed the SSH session. Once again this is largely due to the fact
that if you have SSH access, you can already perform the necessary actions
to change the application through different means.

Another huge hindrance to development, is that the recycling policy is
controlled by administrators. It is not something that normal users can
control, even though we allow the granularity of enabling/disabling SSH
completely to the end user. This seems counterintuitive.

I feel that a better solution would be to provide the user with some
knowledge of which instances may be tainted, and then allowing them to opt
into a policy which will reap tainted containers. This provides users with
clear insight that their application instance may be a snowflake (and that
they may want to take action), while also allowing normal behavior with
regards to SSH access to containers.

To summarize, by enabling the recycling policy by default we not only
produce extremely unusual behavior / workflows for developers, we are also
minimizing the developer-friendliness of CF in general. This mixed with the
fact that as a user I cannot even control this policy, leads me to believe
that as a default recycling should be turned off as it provides the most
cohesive and friendly user experience.

On Mon, Jun 29, 2015 at 9:14 AM, John Wong <gokoproject(a)gmail.com>
wrote:

after executing a command, concluding an interactive session, or
copying a file into an instance, that instance will be restarted.

How does it monitor the behavior? Is there a list of commands
whitelisted? I am curious because I am trying to find out what the
whitelist contain. Also is it at the end of the bosh ssh APP_NAME session?
What if two users are there simultaneously?

Thanks.

On Mon, Jun 29, 2015 at 5:49 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

I think with the CLI we could add clarifying messaging when using ssh
what the current policy around recycling is.
Eric, what do you think about calling it the "recycling" policy,
enabled by default? =D

-Dieu


On Sat, Jun 27, 2015 at 3:42 AM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

Depends on your role and where your app is in the deployment
pipeline. Most of the scenarios I envisioned were for the tail end of
development where you need to poke around to debug and figure out those
last few problems.

For example, Ryan Morgan was saying that the Cloud Foundry plugin
for eclipse is going to be using the ssh support in diego to enable debug
of application instances in the context of a buildpack deployed app. This
is aligned with other requirements I've heard from people working on dev
tools.

As apps reach production, I would hope that interactive ssh is
disabled entirely on the prod space leaving only scp in source mode as an
option (something the proxy can do).

Between dev and prod, there's a spectrum, but in general, I either
expect access to be enabled or disabled - not enabled with a suicidal
tendency.

On Thu, Jun 25, 2015 at 10:53 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

matt,

could you elaborate a bit on what you believe ssh access to
instances is for?


b


On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

My concern is the default behavior.

When I first prototyped this support in February, I never expected
that merely accessing a container would cause it to be terminated. As we
can see from Jan's response, it's completely unexpected; many others have
the same reaction.

I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.

I honestly believe that if we were talking about applying this
behavior to `bosh ssh` and `bosh scp`, few would even consider running in a
'kill on taint mode' because of how useful it is. We should learn from that.

If this behavior becomes the default, I think our platform will be
seen as moving from opinionated to parochial. That would be unfortunate.


On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io>
wrote:

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com
wrote:
On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io>
wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that
instance will
be restarted.
What is the purpose of being able to copy a file into an
instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


Re: CF-Abacus: incubation and inception meeting coming soon

Matt Cowger
 

Stormy - I will happily blog it and take pictures...but you don't want my
notes...I was always the one in college that borrowed notes.

On Thu, Jul 30, 2015 at 3:37 PM, Stormy Peters <speters(a)cloudfoundry.org>
wrote:

Will somebody be taking notes? Would somebody be willing to blog about
this afterwards?

Maybe take a group picture and summarize what was discussed?

Thanks,

Stormy


On Thu, Jul 30, 2015 at 3:31 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

Here is pertinent information for CF-Abacus inception meeting next week.

Invites to those interested is sent. If you want to attend physically then ping me or Devin from CFF on CC: since
we need to add you to the list for the WeWork building.

---------
*Date:* Wednesday August 5th, 2015

*Time:* 9:30am - 12:30pm PDT

*Location:*
CloudFoundry Foundation Offices @ WeWork SF on Mission

WeWork
535 Mission St., *19th floor *
San Francisco, CA

*Room:* 19B

*Call info:*
IBM AT&T Conference Call
USA 888-426-6840; 215-861-6239 | Participant code: 1985291
All other countries, find number here: http://goo.gl/RnNfc1

*Hangout:* TBD
---------

Best,

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


*Michael Maximilien/Almaden/IBM*

07/29/2015 11:35 AM
To
"cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
cc
Subject
Re: CF-Abacus: incubation and inception meeting coming soon




Quick update on inception meeting.

To accommodate our friends and colleagues from Europe who would like to
attend, let's plan to move the meeting to 10a to 12:30p with the option of
lunch after at nearby location in SF.

Unless I hear any objections I will send the invites to those interested
parties who have already contacted me and confirm details here.

If you want to attend (local or remote) please remember to reply to me
with email so I can add you to invite list.

Best,

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

On Jul 28, 2015, at 10:15 PM, Michael Maximilien <*maxim(a)us.ibm.com*
<maxim(a)us.ibm.com>> wrote:

Hi, all,

Now that CF-Abacus is officially an incubator under the guidance of the
CFF, here are some quick updates:

1. The project official github moved to:

*https://github.com/cloudfoundry-incubator/cf-abacus*
<https://github.com/cloudfoundry-incubator/cf-abacus>

2. We are planning an inception next week Wednesday from 2p to 5p in SF.

We invite everyone interested to take a look at the repo, provide
feedback, or better, join us at the inception meeting. The location will be
either CFF, Pivotal, or IBM. All within a few blocks in downtown SF.

We will also have Google hangout and conference call for remote
participants.

If interested, then respond to me directly so I add you to the invite
list.

Thanks and talk next week. Best,

CF-Abacus team

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt


Re: FYI: CAB call for July 2015 - moved to 7/15 @ 8a PDT

Amit Kumar Gupta
 

Hi Guillaume,

Thanks for your question. The best place to start understanding how diego
generates manifests is to look at the manifest generation script in the
diego-release repository:

https://github.com/cloudfoundry-incubator/diego-release/blob/develop/scripts/generate-deployment-manifest

It primarily merges data into the main diego template:

https://github.com/cloudfoundry-incubator/diego-release/blob/develop/manifest-generation/diego.yml

There are several principles operating at the heart of this manifest
generation strategy:

1. The inputs to the script should be a fixed list of stubs with a specific
data structure (not an arbitrary list of stub files which can have all sorts
of crazy structures in their YAML).
2. The YAML structure of the stub should make sense for the purpose of the
stub, i.e. clearly represent the data it contains, it should not represent
the data in some strange contorted format that needs to know where in the
upstream manifest template it will be merged into.
3. Avoid (( merge )) within the body of the template, places that need to
have values filled in explicitly reference the value from the stub that they
need.
4. No nested templates, or "stubs" that have spiff double-parens syntax in
them.
5. Each stub should have a single responsibility (e.g. instance count
overrides, persistent disk overrides, etc.) which should be small and easy
to understand; any two stubs should have orthogonal responsibilities, e.g.
you don't specify some credentials in this stub, and some other credentials
in another stub.
6. The responsibilities of the stubs should be generalizable to any BOSH
release (e.g. "instance count overrides" is a generic enough purpose that
would make sense for any BOSH release.)
7. Have an explicit stub for IaaS settings (basically anything that goes
into a cloud_properties stanza in a BOSH manifest); the main template should
be IaaS agnostic (rather than a template for each IaaS).
8. Cleanliness; do not produce a manifest in the end that has a bunch of
unnecessary junk that BOSH doesn't even use (e.g. "meta"). People tend to
develop the bad habit of depending on this random data.
9. No default property values in the templates; defaults should live in the
job specs, the only properties exposed in the template should be the ones it
makes sense to override.
10. Don't expose every property for override. spiff has hard limitations
that make it impossible to use if you want to construct any arbitrary
deployment manifest for a given release (or set of releases). Given that it
already can't solve every problem, understand that the manifest generation
tooling also doesn't need to solve every possible problem. Advanced users
who want to override obscure properties can use their own advanced tooling.
11. Dovetail with upcoming bosh features:
https://github.com/cloudfoundry/bosh-notes/blob/master/links.md
https://github.com/cloudfoundry/bosh-notes/blob/master/global-networking.md
https://github.com/cloudfoundry/bosh-notes/blob/master/cloud-config.md
https://github.com/cloudfoundry/bosh-notes/blob/master/availability-zones.md

The long-term goal is to make BOSH smarter and ideally obviate the need for
complex tooling to generate these unwieldy, several-thousand-line YAML
manifests. On the surface, both diego-release and cf-release suggest how to
use spiff to generate manifests, but the way the two use spiff is
drastically different. With diego, we've started by simplifying how
manifests are generated so that the full power of spiff isn't needed, and
identifying better abstractions that make sense for BOSH to know about so
that eventually none of the power of spiff is needed.



-----
Amit, CF OSS Release Integration PM
Pivotal Software, Inc.
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-CAB-call-for-July-2015-moved-to-7-15-8a-PDT-tp645p986.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: SSH access to CF app instances on Diego

Gwenn Etourneau
 

Guillaume,

Not sure is related but the ssh have been already implemented and is
available on diego and cf-release.


On Thu, Jul 30, 2015 at 10:35 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Eric,

The CAB minutes [1] mentionned you were still looking for feedback from
the community on the policy for altered instances, but this thread seems
silent for a while.

Not sure you had seen my email and suggestion below for a way to
quarantine the altered instances (beyond the per-space restart policy
configuration). Such quarantine request might be a good place to include
option to ask for the quarantine instances to be excluded from gorouter
traffic.

[1]
http://www.activestate.com/blog/2015/07/cloud-foundry-advisory-board-meeting-2015-july

Regards,

Guillaume.

On Fri, Jul 3, 2015 at 3:56 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

please find my feedback to this thread

*short version:*
1- need preserve good CF experience with HTTP only (direct SSH flow is
still blocked and a pain in many organisations) => +1 to preserve "cf
files" or fine tune diego plug to have ssh over HTTP to work out of the box
2- default "recycle tainted containers by default" policy seems good to me
3- needs to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )
4- development use-cases need to be better supported (dev/prod parity)
not sure ssh/scp is the right path though

*long version:*

*1- cf files and ssh over HTTP*

As previously mentionned into [1], CF exposing apis over HTTP api made a
great job to be easily consummed through HTTP proxies that some companies
still use, making CF experience seemless to consumme public paas, or
private paas among corporate entities. It seems important to me to preserve
good CF experience with HTTP only.

If SSH interactive access, scp and port forwarding become the mainstream
solution to operate and troubleshoot apps (supporting "cf files",
replacement for the previous DEBUG and CONSOLE ports), it will be useful
for users behind such firewalls to be able to configure diego ssh plugin to
use HTTP/SOCKS proxies to reach public CF instances. As the diego ssh cli
plugin supports using the regular local host ssh binaries, this may
potentially be done by tweaking the .ssh config file to add flags
associated to host ssh.${domain} to go through proxies (possibly double
tunnels as described into [2]). However, for new users in such network
context, especially on windows operating system, the set up work before
using a CF public instance starts to add up?

*2- default "recycle tainted containers by default" seems good to me*

Given that apps deployed on CF comply to 12 factor apps, there instance
may be restarted at anytime (e.g. during a CF new release deployment or
stemcell upgrade). So the default policy "recycle tainted containers by
default" is not a surprise.

*3- need to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )*

There are some specific use-cases where the "recycle tainted containers
by default" policy would be problematic when running applications in
production:

An application instance is malfunctionning (e.g. hanging) and an
interactive debugging is necessary. The app-ops ssh into the container and
starts taking some diagnostic steps (e.g sending kill -SIGTERM signals to
take thread dumps, or locally changes log levels).

If ever the ssh connection breaks/timeout, the "recycle tainted
containers by default, preventing the current diagnostc to complete.

Another similar use case: a production application is suspected to be
compromised by an attacker. App-ops need to capture evidences and
understand better how the abuse was done. There isn't enough information in
streamed logs, and there is a need to get into the container to inspect the
ephemeral FS and the processes and memory. This may require more than one
simultanenous SSH connection, and may span on multiple hours

In both use-cases above, while the application is 12 factor compliant and
the "recycle tainted containers by default" policy would be opted in on the
corresponding space, there would be a need to transiently turn the mode off.

In term of user experience, this may appear as an explicit user request
to "quarantine" the tainted app instances (or the whoe app) so that CF does
not attempt to restart them. Or it may appear as the google app engine
"lock/unlock"

a call to a new "unlock" command to a CF app instance would be necessary
to get SSH access to it. CF then considers this instance as
"tained"/untrusted, as it may have deviated from the pushed content, and
does not act to it anymore (i.e. does not monitor its bound $PORT or root
process exit, which may be handy to diagnose it as wish). When the "lock"
command is requested on this instance, Cf destroys this tainted instance,
and recreates a fresh new "trusted" one.

*4- development use-cases need to be better supported (dev/prod parity)
not sure ssh/scp is the right path though*

I agree with James Myers that development use-cases should be better
supported.

First, CF should strive to support dev-prod parity [4]. However
currently, there is not anymore a version of CF that a developper can run
on his laptop (e.g. when doing offline development during commute) that
would behave like prod and embed buildpacks. There used to have "CF on a
single VM". Heroku or GAE have emulators. Cloud rocker [5] is close, but it
still takes 10s or more to have changes made on the app be reflected into a
running app.

There are some legitimate use cases during development for modifying
sources of the application and have those changes be taken in effect
immediately. Lots of app development framework supports those development
modes (even those that promote test-driven practices), and getting a fast
feedback is important. Having dev-prod parity means supporting these use
cases while preserving prod behavior (having the VCAP_SERVICES and
VCAP_APPLICATION and the buildpack processing applied on the same stack
(cflinux2)). Being able to run offline would be even better.

I however believe that providing SSH/SCP access to change the file system
to a running app instance may not be the appropriate response, given the FS
and the app instance is still ephemeral. Who would want to modify files
that could be lost at any time (e.g. a stemcell upgrade ) ?

I'd rather see value in further exploring the ideas layed out by James
Bayer into [5] e.g. as a form of a git repo populated with the
/home/vcap/app subdir, that developers could clone, push to, and have the
instance epheremal FS updated with pushed changes.

This may be combined with a cloudrocker mechanism as to work with a fully
offline mode when this is required.

[1]
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/OavSBIhU_xQ/wJrT08iHfJ8J
[2] http://proxytunnel.sourceforge.net/paper.php
[3]
https://cloud.google.com/appengine/docs/managed-vms/host-env#changing_management
[4] http://12factor.net/dev-prod-parity
[5]
https://docs.google.com/document/d/1_C3OWS6giWx4JL_IL9YLA6jcppyQLVD-YjR0GeA8Z0s/edit#heading=h.toypuu5pxh65



On Thu, Jul 2, 2015 at 10:18 PM, James Myers <jmyers(a)pivotal.io> wrote:

I have to agree with Matt on this one. I feel that the recycling of
containers is a very anti-developer default. When you approach Cloud
Foundry from the perspective of running production applications the recycle
policy makes complete sense. However, I feel that this misses out on one of
the massive benefits/use cases of Cloud Foundry, what it offers to the
development process.

From a security stand point, if you can ssh into a container, it means
you have write access to the application in CloudFoundry. Thus you can
already push new bits/change the application in question. All of the
"papertrail" functionality around pushing/changing applications exists for
SSH as well (we record events, output log lines, make it visible to users
that action was taken on the application), and thus concerned operators
would be able to determine if someone modifying the application in question.

Therefore I'm lost on how this is truly the most secure default. If we
are really going by the idea that all defaults should be the most secure,
ssh should be disabled by default.

As a developer, I can see many times in which I would want to be able to
ssh into my container and change my application as part of a
troubleshooting process. Using BOSH as an example, CF Devs constantly ssh
into VMs and change the processes running on them in order to facilitate
development. BOSH does not reap the VM and redeploy a new instance when you
have closed the SSH session. Once again this is largely due to the fact
that if you have SSH access, you can already perform the necessary actions
to change the application through different means.

Another huge hindrance to development, is that the recycling policy is
controlled by administrators. It is not something that normal users can
control, even though we allow the granularity of enabling/disabling SSH
completely to the end user. This seems counterintuitive.

I feel that a better solution would be to provide the user with some
knowledge of which instances may be tainted, and then allowing them to opt
into a policy which will reap tainted containers. This provides users with
clear insight that their application instance may be a snowflake (and that
they may want to take action), while also allowing normal behavior with
regards to SSH access to containers.

To summarize, by enabling the recycling policy by default we not only
produce extremely unusual behavior / workflows for developers, we are also
minimizing the developer-friendliness of CF in general. This mixed with the
fact that as a user I cannot even control this policy, leads me to believe
that as a default recycling should be turned off as it provides the most
cohesive and friendly user experience.

On Mon, Jun 29, 2015 at 9:14 AM, John Wong <gokoproject(a)gmail.com>
wrote:

after executing a command, concluding an interactive session, or
copying a file into an instance, that instance will be restarted.

How does it monitor the behavior? Is there a list of commands
whitelisted? I am curious because I am trying to find out what the
whitelist contain. Also is it at the end of the bosh ssh APP_NAME session?
What if two users are there simultaneously?

Thanks.

On Mon, Jun 29, 2015 at 5:49 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

I think with the CLI we could add clarifying messaging when using ssh
what the current policy around recycling is.
Eric, what do you think about calling it the "recycling" policy,
enabled by default? =D

-Dieu


On Sat, Jun 27, 2015 at 3:42 AM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

Depends on your role and where your app is in the deployment
pipeline. Most of the scenarios I envisioned were for the tail end of
development where you need to poke around to debug and figure out those
last few problems.

For example, Ryan Morgan was saying that the Cloud Foundry plugin for
eclipse is going to be using the ssh support in diego to enable debug of
application instances in the context of a buildpack deployed app. This is
aligned with other requirements I've heard from people working on dev tools.

As apps reach production, I would hope that interactive ssh is
disabled entirely on the prod space leaving only scp in source mode as an
option (something the proxy can do).

Between dev and prod, there's a spectrum, but in general, I either
expect access to be enabled or disabled - not enabled with a suicidal
tendency.

On Thu, Jun 25, 2015 at 10:53 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

matt,

could you elaborate a bit on what you believe ssh access to
instances is for?


b


On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

My concern is the default behavior.

When I first prototyped this support in February, I never expected
that merely accessing a container would cause it to be terminated. As we
can see from Jan's response, it's completely unexpected; many others have
the same reaction.

I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.

I honestly believe that if we were talking about applying this
behavior to `bosh ssh` and `bosh scp`, few would even consider running in a
'kill on taint mode' because of how useful it is. We should learn from that.

If this behavior becomes the default, I think our platform will be
seen as moving from opinionated to parochial. That would be unfortunate.


On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io>
wrote:

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com>
wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io>
wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that
instance will
be restarted.
What is the purpose of being able to copy a file into an instance
if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: App autosleep support

Gwenn Etourneau
 

For the autosleep feature why not but again only for non-prod application.

In my previous company, for DEV environment we stop application which have
been not updated since one month except some exception.
We considered that DEV is for active development.
Was just a batch script looking in the CCDB and calling cf-cli to stop
apps.

On Thu, Jul 30, 2015 at 7:46 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Hi,

I wonder if there are plans to implement an auto-sleep behavior in
cloudfoundry, in which inactive apps would be automatically stopped after a
max inactivity threshold, and automatically restart upon arrival of traffic
on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of
our non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such
feature or would be interested in collaborating on an opensource
implementation.

I drafted some specs for a java-based implementation we're planning to
work on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: CF-Abacus: incubation and inception meeting coming soon

Stormy
 

Will somebody be taking notes? Would somebody be willing to blog about this
afterwards?

Maybe take a group picture and summarize what was discussed?

Thanks,

Stormy


On Thu, Jul 30, 2015 at 3:31 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

Here is pertinent information for CF-Abacus inception meeting next week.

Invites to those interested is sent. If you want to attend physically then ping me or Devin from CFF on CC: since
we need to add you to the list for the WeWork building.

---------
*Date:* Wednesday August 5th, 2015

*Time:* 9:30am - 12:30pm PDT

*Location:*
CloudFoundry Foundation Offices @ WeWork SF on Mission

WeWork
535 Mission St., *19th floor *
San Francisco, CA

*Room:* 19B

*Call info:*
IBM AT&T Conference Call
USA 888-426-6840; 215-861-6239 | Participant code: 1985291
All other countries, find number here: http://goo.gl/RnNfc1

*Hangout:* TBD
---------

Best,

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


*Michael Maximilien/Almaden/IBM*

07/29/2015 11:35 AM
To
"cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
cc
Subject
Re: CF-Abacus: incubation and inception meeting coming soon




Quick update on inception meeting.

To accommodate our friends and colleagues from Europe who would like to
attend, let's plan to move the meeting to 10a to 12:30p with the option of
lunch after at nearby location in SF.

Unless I hear any objections I will send the invites to those interested
parties who have already contacted me and confirm details here.

If you want to attend (local or remote) please remember to reply to me
with email so I can add you to invite list.

Best,

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

On Jul 28, 2015, at 10:15 PM, Michael Maximilien <*maxim(a)us.ibm.com*
<maxim(a)us.ibm.com>> wrote:

Hi, all,

Now that CF-Abacus is officially an incubator under the guidance of the
CFF, here are some quick updates:

1. The project official github moved to:

*https://github.com/cloudfoundry-incubator/cf-abacus*
<https://github.com/cloudfoundry-incubator/cf-abacus>

2. We are planning an inception next week Wednesday from 2p to 5p in SF.

We invite everyone interested to take a look at the repo, provide
feedback, or better, join us at the inception meeting. The location will be
either CFF, Pivotal, or IBM. All within a few blocks in downtown SF.

We will also have Google hangout and conference call for remote
participants.

If interested, then respond to me directly so I add you to the invite list.

Thanks and talk next week. Best,

CF-Abacus team

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Removing FUSE support from CF

Onsi Fakhouri <ofakhouri@...>
 

Yes, and perhaps I wasn't very clear about that. Thanks for teasing that
out Mike.

Onsi

On Thu, Jul 30, 2015 at 2:27 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Right. So to restate this discussion only applies to buildpack containers
docker containers currently are and will continue to be run in unprivileged
mode by default. Correct?

On Thu, Jul 30, 2015 at 2:47 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Hey Mike,

Just to be clear, I think you have a (consistent) sign error throughout
your e-mail?

Cloud Controller's current behavior is to request *un*privileged (i.e.
"more secure") containers for Docker images and privileged (i.e. "less
secure") containers for buildpack apps.

Our proposal is to make the privileged flag for buildpack apps
configurable (and it sounds like folks are leaning towards the per-space
approach).

I think we want to continue to enforce *un*privileged containers for
docker images as the attack surface is substantially higher with a docker
image.

Onsi



On Thu, Jul 30, 2015 at 12:39 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Good description. Count us as one who does not use FUSE and would very
much like to run docker images in privileged mode.

Perhaps it would be appropriate to force privileged mode for docker apps
but allow running non privileged for non docker applications until FUSE can
be removed?

Mike



On Thu, Jul 30, 2015 at 10:34 AM, Julian Friedman <
julz.friedman(a)gmail.com> wrote:

Hi Guillaume, I'd put it like this: running containers with
'privileged: false' makes them safe /even if/ a user gets root. With a
docker image this is essential, because getting root is trivial. With a
buildpack image this is less essential, but it means /even if/ a root
escalation exploit is found (these do exist, there was an escalation via
overlayfs patched a while ago) you're still safe. 'Privileged: false' turns
on user namespacing and turns off various capabilities: it's what the
Garden team recommend most containers use. 'Privileged: true' relies on the
security of your rootfs and users never getting root; if your use case
requires it you'll of course need to make a judgement, but you're trading
off quite a lot of security in my opinion.

Sent from my iPhone

On 30 Jul 2015, at 17:12, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Onsi. Being able to use FUSE is quite important to us too.

Can you clarify the security risk associated with running a privileged
container (as a workaround for the lack of fuse support within user
namespace), when pushing an app that goes through the buildpack staging
process (hence running as vcap user) ?

From http://godoc.org/github.com/cloudfoundry-incubator/garden I see

// If Privileged is true the container does not have a user namespace and the root user in the container
// is the same as the root user in the host. Otherwise, the container has a user namespace and the root
// user in the container is mapped to a non-root user in the host. Defaults to false.
Privileged bool <http://godoc.org/builtin#bool> `json:"privileged,omitempty"`


I understand the risk is specific to running a docker image built using
the docker file USER directive (specially root): then the container will
run as the host root ?

BTW, is the ability to run as a different user in staging and running
currently considered as discussed into
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/ZlC-2DVOSHo/uRrF6Io52mEJ
?

Thanks,

Guillaume.

On Thu, Jul 30, 2015 at 3:27 AM, Jack Cai <greensight(a)gmail.com> wrote:

+1 for space-level configuration.

Jack

On Wed, Jul 29, 2015 at 2:04 PM, Matt Cowger <matt(a)cowger.us> wrote:

We're wary of adding too many knobs to the platform and exposing
them all the way down to app developers increases the cognitive load for
folks using the platform. Enabling/disabling it on a per-installation
level, and - maybe - a per-space level, might be a decent compromise?

Agreed. I'd argue this this probably not be a 'per-app' thing, as I
too amy way of the knobs that developers like to turn. I think a per space
level is just the right level.

On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io
wrote:
That's still very much open for discussion. Obviously, someone with
administrative privileges should be in charge of this particular piece of
configuration.

Also making this a runtime config (e.g. feature flag) as opposed to
a deploy-time config (e.g. part of the CC config written out by BOSH) would
make the different behaviors more testable.

Thoughts? Preferences? We're wary of adding too many knobs to the
platform and exposing them all the way down to app developers increases the
cognitive load for folks using the platform. Enabling/disabling it on a
per-installation level, and - maybe - a per-space level, might be a decent
compromise?

Onsi



On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:

Once - configurable on a per-app, per space, or per deployment
basis?

On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <
ofakhouri(a)pivotal.io> wrote:

Hey all,

Based on the feedback we got and the relatively low cost to
maintain privileged support we'd like to propose making running privileged
containers on the platform configurable - we will recommend this be turned
off when running untrusted workloads and it will likely default to off. We
have longer term plans to support mounting persistent volumes in Diego at
which point support for mounting FUSE in unprivileged containers can become
a reality.

Thoughts?

Onsi

On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io
wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <
vedran.lerenc(a)sap.com> wrote:

Hi Onsi,



Ø Thoughts? Concerns?



Well, that’s bad news.



We, and I assume many others as well (like the folks from
Stackato who do it in the public), have used SSHFS + FUSE to implement a
persistent file system for old-fashioned apps/apps that are not
Cloud-native. I don’t want to fight an ideological battle here, it’s just
that these apps do still exist (in majority) and a file system service is
an important service/feature for them.



So if you remove FUSE (which we thought is not going away/was
added to stay), it’s pretty bad for us/many apps.



Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very
helpful for running apps that depend on a persistent FS, like Wordpress.
Perhaps this use case of mounting a remote SSHFS could be supported in some
other way?

Dan








*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the
system overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF



Hey CF-Dev,



The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!



Diego currently runs applications in *privileged* containers.
These lack the security features outlined above and we are planning on
switching to launch all CF applications in *unprivileged*
containers.



Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers
becomes possible we may add it back to the platform.



Thoughts? Concerns?



Thanks!



Onsi

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: CF-Abacus: incubation and inception meeting coming soon

Michael Maximilien
 

Hi, all,

Here is pertinent information for CF-Abacus inception meeting next week.

Invites to those interested is sent. If you want to attend physically then ping me or Devin from CFF on CC: since
we need to add you to the list for the WeWork building.

---------
Date: Wednesday August 5th, 2015

Time: 9:30am - 12:30pm PDT

Location:
CloudFoundry Foundation Offices @ WeWork SF on Mission

WeWork
535 Mission St., 19th floor
San Francisco, CA

Room: 19B

Call info:
IBM AT&T Conference Call
USA 888-426-6840; 215-861-6239 | Participant code: 1985291
All other countries, find number here: http://goo.gl/RnNfc1

Hangout: TBD
---------

Best,

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



Michael Maximilien/Almaden/IBM
07/29/2015 11:35 AM

To
"cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
cc

Subject
Re: CF-Abacus: incubation and inception meeting coming soon






Quick update on inception meeting.

To accommodate our friends and colleagues from Europe who would like to
attend, let's plan to move the meeting to 10a to 12:30p with the option of
lunch after at nearby location in SF.

Unless I hear any objections I will send the invites to those interested
parties who have already contacted me and confirm details here.

If you want to attend (local or remote) please remember to reply to me
with email so I can add you to invite list.

Best,

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

On Jul 28, 2015, at 10:15 PM, Michael Maximilien <maxim(a)us.ibm.com> wrote:

Hi, all,

Now that CF-Abacus is officially an incubator under the guidance of the
CFF, here are some quick updates:

1. The project official github moved to:

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

2. We are planning an inception next week Wednesday from 2p to 5p in SF.

We invite everyone interested to take a look at the repo, provide
feedback, or better, join us at the inception meeting. The location will
be either CFF, Pivotal, or IBM. All within a few blocks in downtown SF.

We will also have Google hangout and conference call for remote
participants.

If interested, then respond to me directly so I add you to the invite
list.

Thanks and talk next week. Best,

CF-Abacus team

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone


Re: Removing FUSE support from CF

Mike Youngstrom <youngm@...>
 

Right. So to restate this discussion only applies to buildpack containers
docker containers currently are and will continue to be run in unprivileged
mode by default. Correct?

On Thu, Jul 30, 2015 at 2:47 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote:

Hey Mike,

Just to be clear, I think you have a (consistent) sign error throughout
your e-mail?

Cloud Controller's current behavior is to request *un*privileged (i.e.
"more secure") containers for Docker images and privileged (i.e. "less
secure") containers for buildpack apps.

Our proposal is to make the privileged flag for buildpack apps
configurable (and it sounds like folks are leaning towards the per-space
approach).

I think we want to continue to enforce *un*privileged containers for
docker images as the attack surface is substantially higher with a docker
image.

Onsi



On Thu, Jul 30, 2015 at 12:39 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Good description. Count us as one who does not use FUSE and would very
much like to run docker images in privileged mode.

Perhaps it would be appropriate to force privileged mode for docker apps
but allow running non privileged for non docker applications until FUSE can
be removed?

Mike



On Thu, Jul 30, 2015 at 10:34 AM, Julian Friedman <
julz.friedman(a)gmail.com> wrote:

Hi Guillaume, I'd put it like this: running containers with 'privileged:
false' makes them safe /even if/ a user gets root. With a docker image this
is essential, because getting root is trivial. With a buildpack image this
is less essential, but it means /even if/ a root escalation exploit is
found (these do exist, there was an escalation via overlayfs patched a
while ago) you're still safe. 'Privileged: false' turns on user namespacing
and turns off various capabilities: it's what the Garden team recommend
most containers use. 'Privileged: true' relies on the security of your
rootfs and users never getting root; if your use case requires it you'll of
course need to make a judgement, but you're trading off quite a lot of
security in my opinion.

Sent from my iPhone

On 30 Jul 2015, at 17:12, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Onsi. Being able to use FUSE is quite important to us too.

Can you clarify the security risk associated with running a privileged
container (as a workaround for the lack of fuse support within user
namespace), when pushing an app that goes through the buildpack staging
process (hence running as vcap user) ?

From http://godoc.org/github.com/cloudfoundry-incubator/garden I see

// If Privileged is true the container does not have a user namespace and the root user in the container
// is the same as the root user in the host. Otherwise, the container has a user namespace and the root
// user in the container is mapped to a non-root user in the host. Defaults to false.
Privileged bool <http://godoc.org/builtin#bool> `json:"privileged,omitempty"`


I understand the risk is specific to running a docker image built using
the docker file USER directive (specially root): then the container will
run as the host root ?

BTW, is the ability to run as a different user in staging and running
currently considered as discussed into
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/ZlC-2DVOSHo/uRrF6Io52mEJ
?

Thanks,

Guillaume.

On Thu, Jul 30, 2015 at 3:27 AM, Jack Cai <greensight(a)gmail.com> wrote:

+1 for space-level configuration.

Jack

On Wed, Jul 29, 2015 at 2:04 PM, Matt Cowger <matt(a)cowger.us> wrote:

We're wary of adding too many knobs to the platform and exposing
them all the way down to app developers increases the cognitive load for
folks using the platform. Enabling/disabling it on a per-installation
level, and - maybe - a per-space level, might be a decent compromise?

Agreed. I'd argue this this probably not be a 'per-app' thing, as I
too amy way of the knobs that developers like to turn. I think a per space
level is just the right level.

On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

That's still very much open for discussion. Obviously, someone with
administrative privileges should be in charge of this particular piece of
configuration.

Also making this a runtime config (e.g. feature flag) as opposed to a
deploy-time config (e.g. part of the CC config written out by BOSH) would
make the different behaviors more testable.

Thoughts? Preferences? We're wary of adding too many knobs to the
platform and exposing them all the way down to app developers increases the
cognitive load for folks using the platform. Enabling/disabling it on a
per-installation level, and - maybe - a per-space level, might be a decent
compromise?

Onsi



On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:

Once - configurable on a per-app, per space, or per deployment basis?

On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io
wrote:
Hey all,

Based on the feedback we got and the relatively low cost to
maintain privileged support we'd like to propose making running privileged
containers on the platform configurable - we will recommend this be turned
off when running untrusted workloads and it will likely default to off. We
have longer term plans to support mounting persistent volumes in Diego at
which point support for mounting FUSE in unprivileged containers can become
a reality.

Thoughts?

Onsi

On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <
vedran.lerenc(a)sap.com> wrote:

Hi Onsi,



Ø Thoughts? Concerns?



Well, that’s bad news.



We, and I assume many others as well (like the folks from
Stackato who do it in the public), have used SSHFS + FUSE to implement a
persistent file system for old-fashioned apps/apps that are not
Cloud-native. I don’t want to fight an ideological battle here, it’s just
that these apps do still exist (in majority) and a file system service is
an important service/feature for them.



So if you remove FUSE (which we thought is not going away/was
added to stay), it’s pretty bad for us/many apps.



Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very
helpful for running apps that depend on a persistent FS, like Wordpress.
Perhaps this use case of mounting a remote SSHFS could be supported in some
other way?

Dan








*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the
system overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF



Hey CF-Dev,



The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!



Diego currently runs applications in *privileged* containers.
These lack the security features outlined above and we are planning on
switching to launch all CF applications in *unprivileged*
containers.



Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers
becomes possible we may add it back to the platform.



Thoughts? Concerns?



Thanks!



Onsi

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev