Re: UAA: How to set client_credentials token grant type to not expire
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
toggle quoted message
Show quoted text
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
|
|
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.
toggle quoted message
Show quoted text
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.
toggle quoted message
Show quoted text
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?
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
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.
toggle quoted message
Show quoted text
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?
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>:
toggle quoted message
Show quoted text
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
Oh I think you are right James .. Do we have a google docs discussing around that ?
toggle quoted message
Show quoted text
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
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
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
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
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-manifestIt primarily merges data into the main diego template: https://github.com/cloudfoundry-incubator/diego-release/blob/develop/manifest-generation/diego.ymlThere 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.mdhttps://github.com/cloudfoundry/bosh-notes/blob/master/global-networking.mdhttps://github.com/cloudfoundry/bosh-notes/blob/master/cloud-config.mdhttps://github.com/cloudfoundry/bosh-notes/blob/master/availability-zones.mdThe 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.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
Re: SSH access to CF app instances on Diego
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
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.
toggle quoted message
Show quoted text
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
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
toggle quoted message
Show quoted text
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
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
toggle quoted message
Show quoted text
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-abacus2. 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?
toggle quoted message
Show quoted text
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
|
|