|
Re: Incubation Proposal: CredHub (credential manager)
Justin Smith
It makes sense to build CredHub for many reasons. A few that come to mind quickly are below.
1) The service must start and restart without human intervention. This immediately means the key encrypting key resides in a Hardware Security Module (HSM) of some kind. We think this is a first-class feature and should be part of CredHub open source. 2) CloudFoundry runs in production in some of the most restricted environments in the world. These environments tend towards favoring crypto stacks they have seen and reviewed before. The Java ecosystem contains several. The Go ecosystem will eventually get there, but it isn't right now. We're fully aware there are tons of great Go apps (including large chunks of CloudFoundry) that perform crypto today. We received credible feedback that showed a Java preference for this type of application. 3) Authorization is an important part of credential management in CF. Authorization can be an incredibly difficult problem, and an authorization implementation can be very hard to change after it is built. We didn't see anything available that had the right feature set. We could have bolted something in front of another product, but we decided it made more sense to build something new. MVP certainly requires hitting a threshold of capabilities, but it also requires leaving runway for what's ahead. App secrets are a mainline scenario. Let's take it as a given that apps must have access to plaintext secrets. From there, the discussion centers on two questions: 1) what's the chain of custody of the secret and what has access to it, and 2) how is the secret made available to the app. (1) is all about CredHub and (2) is mostly about Diego. We'll engage in a discussion on these in the weeks ahead. |
|
|
|
Re: consul_z1/0 is failing after update
Yitao Jiang
we once had the same issue which causing by network issue, the consul
server follower couldn't connect to the leader, but what difference is that we are running on openstack. On Tue, Dec 20, 2016 at 12:32 AM, Sylvain Gibier < sylvain(a)munichconsulting.de> wrote: Hi, -- Regards, Yitao |
|
|
|
Re: Incubation Proposal: CredHub (credential manager)
Allan Beck
I am supportive of the proposal. We have our own credentials store implementation to encrypt the service credentials passed to applications (so devops staff can’t see credentials to production services). CredHub will be a useful addition to CF and will allow us to use this community component rather than our bespoke implementation.
toggle quoted message
Show quoted text
Regards, Allan. On 19 Dec 2016, at 06:42, John Feminella <jxf(a)pivotal.io> wrote: |
|
|
|
Re: container restart on logout
Jon Price
This is something that has been on our wishlist as well but I haven't seen any discussion about it in quite some time. Here is one of the original discussions about it: https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/GCFOOYRUT5ARBMUHDGINID46KFNORNYM/
It would go a long way with our security team if we could have some sort of recycling policy for containers in some of our more secure environments. Jon Price Intel Corporation |
|
|
|
Re: Incubation Proposal: CredHub (credential manager)
David Illsley <davidillsley@...>
It seems like the initial focus is solving the operator problems (via BOSH)
toggle quoted message
Show quoted text
rather than app developer problems. Do you have any sketches of how it might be used for application secrets (broker and user provided)? On Fri, Dec 16, 2016 at 11:15 PM, Dan Jahner <djahner(a)pivotal.io> wrote:
Hello Everyone, |
|
|
|
consul_z1/0 is failing after update
Sylvain Gibier
Hi,
Diego has been default in my CF installation (H/A over 3 AZ) - and today, while trying a simple BOSH CF update of a stemcell - the consul_z1/0 keeps on "failing after update". If I look in the log file - I can see the following: " ++ logger -p user.info -t vcap.consul-agent ++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log error during start: 2/30 nodes reported failure 2016/12/19 14:49:50 [ERR] agent.client: Failed to decode response header: EOF 2016/12/19 14:49:50 [ERR] agent.client: Failed to decode response header: EOF " Also it seems that I have a bunch of errors: " 2016/12/19 13:54:32 [INFO] consul: adding server consul-z3-0 (Addr: 10.10.30.37:8300) (DC: dc1) 2016/12/19 13:54:32 [INFO] consul: adding server consul-z2-0 (Addr: 10.10.20.37:8300) (DC: dc1) 2016/12/19 13:54:32 [ERR] agent: failed to sync remote state: No cluster leader 2016/12/19 13:54:32 [INFO] agent: Joining cluster... 2016/12/19 13:54:32 [INFO] agent: (LAN) joining: [10.10.10.37 10.10.20.37 10.10.30.37] 2016/12/19 13:54:32 [INFO] agent: (LAN) joined: 3 Err: <nil> 2016/12/19 13:54:32 [INFO] agent: Join completed. Synced with 3 initial agents 2016/12/19 13:54:32 [WARN] raft: Failed to get previous log: 503710 log not found (last: 503708) 2016/12/19 13:54:32 [INFO] raft: Removed ourself, transitioning to follower " I can definitely confirm in my case - that consul_z3 is the Leader (via consul info) in my current setup. Any help/point on how to fix that ? Releases: CF: v234, Diego: 0.1467.0 IaaS: AWS |
|
|
|
container restart on logout
DHR
Hi,
Last year when ‘cf ssh’ functionality was being discussed, I’m pretty sure that the concept of automatically restarting containers following an SSH session was discussed. It was to protect against creating app container snowflakes. I’m fairly sure that protection hasn’t been introduced yet: I tested cf ssh-ing into a PCFDEV container today, writing a file & was able to log back in to the container later and see that it was still present. Is this feature or any other app container snowflake protection still planned? I couldn’t see anything in the Diego backlog (https://www.pivotaltracker.com/n/projects/1003146 <https://www.pivotaltracker.com/n/projects/1003146>). Thanks Dave |
|
|
|
Re: Incubation Proposal: CredHub (credential manager)
John Feminella <jxf@...>
Questions: * To what extent are CredHub's use cases and architecture covered
toggle quoted message
Show quoted text
(or not) by a combination of something like Hashicorp's Vault and integration effort? (I'm not singling out Vault specifically here, just using it as a representative member of a class.) * People who use CF want the properties outlined by CredHub, but CredHub doesn't exist yet. What do those people do instead? To what extent are their current solutions sufficient or deficient? best, ~ jf--John Feminella Advisory Platform Architect ✉ ·jxf(a)pivotal.io t · @jxxf On Fri, Dec 16, 2016 6:15 PM, Dan Jahner djahner(a)pivotal.io
wrote: Hello Everyone, Pivotal would like to propose to the Extensions PMC a new incubation project focusing on credential management in Cloud Foundry. This product may be used in a Cloud Foundry environment to centralize and secure credential generation, storage, lifecycle management and access. Project name: CredHubProject proposal: https://docs.google.com/document/d/1iG28J2Lm8RY3BXCZqqNWO7v-G1ppcdK8cizlhbN_o4g/edit?usp=sharing Proposed Project Lead: Dan Jahner (Pivotal)Proposed Scope: See “Proposed Scope” in the proposalDevelopment Operating Model: Pairing ModelTechnical Approach: See “Basic Architecture” and “BOSH Manifest Implementation” in the proposalInitial team committed: 6 engineers from Pivotal Please let me know if you have any questions. Thanks,Dan Jahnerdjahner(a)pivotal.io |
|
|
|
Hardcoded port in HM9k code & DEA job templates
Ronak Banka
Hello,
Recently we caught a hardcoded port in hm9k code which was mentioned nowhere in release notes , and is still sitting there in hm9k code and dea job templates. Would be interested to know , how other cf operators are tracking this , specially from security point of view where ACL can break whole platform. Opened a issue on cf-release https://github.com/cloudfoundry/cf-release/issues/1128 Thanks Ronak Rakuten Inc. -- View this message in context: http://cf-dev.70369.x6.nabble.com/Hardcoded-port-in-HM9k-code-DEA-job-templates-tp6249.html Sent from the CF Dev mailing list archive at Nabble.com. |
|
|
|
Re: Introducing hummus
Ronak Banka
Hi Adi,
Thanks for sharing , but i am not sure how this project is related to cloudfoundry core or related projects ? Thanks Ronak -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Introducing-hummus-tp6247p6248.html Sent from the CF Dev mailing list archive at Nabble.com. |
|
|
|
Introducing hummus
Aditya Anchuri
Hi all,
I worked on a little side project recently in order to create what I believe to be a simpler way of generating JSON in Go (especially when dealing with nested objects/arrays, or when cherry-picking elements from one JSON message in order to create another JSON message). I'd like to share it with everybody, hoping you'd find this useful. The README is pretty self-explanatory, but let me know if you have any questions. https://github.com/aditya87/hummus Thanks, -Adi |
|
|
|
Introducing hummus
Aditya Anchuri
Hi all,
I worked on a little side project recently in order to create what I believe to be a simpler way of generating JSON in Go (especially when dealing with nested objects/arrays, or when cherry-picking elements from one JSON message in order to create another JSON message). I'd like to share it with everybody, hoping you'd find this useful. The README is pretty self-explanatory, but let me know if you have any questions. https://github.com/aditya87/hummus Thanks, -Adi |
|
|
|
CF Diego Operator Toolkit: now on your Diego VMs!
Eric Malm <emalm@...>
Hi, all,
Over the past few months, the Diego team has been working on a new, operator-focused CLI tool, which we call cfdot, the CF Diego Operator Toolkit (https://github.com/cloudfoundry/cfdot). We have focused initially on providing commands for the Diego BBS API, mainly representing its endpoints (https://github.com/ cloudfoundry/bbs/tree/master/doc) directly. At present, we've added commands for inspecting and manipulating DesiredLRPs and ActualLRPs, which correspond to your CF app definitions and instances, and we have stories to fill out commands for Tasks and Cells next. These BBS commands all return a stream of JSON values on stdout, for easy processing with tools such as jq. We plan eventually to build cfdot out at least to match the most valuable capabilities of the previous "veritas" tool that some of you may have used in the past. If you're interested in trying it out, and you have a Diego deployment based on the manifest-generation scripts in diego-release, it's already available for you! Simply bosh ssh to any Diego job and run source /var/vcap/jobs/cfdot/bin/setup: this command will put a BOSH-deployed cfdot binary on your PATH and configure some environment variables for cfdot to communicate with the BBS API for that deployment. It also adds a BOSH-deployed jq binary to the PATH, for easier manipulation of those JSON streams. As an example, here's one way to add up the total number of app instances CC has told Diego to run: $ cfdot desired-lrp-scheduling-infos | jq '.instances' | jq -s 'add' 26 At this point, we have focused on making cfdot self-discoverable via help and usage text instead of producing much external documentation about it. If you do try it out, we would certainly appreciate feedback about it: what's delightful, what's frustrating, what problems you are solving or would like to solve with it that we can help you solve more directly, and so forth. As an example, we've already received feedback that it would be useful to have a script that sets up the environment to communicate with the BBS in the standard BOSH-Lite deployment. Please feel free to reply on this mailing list thread or open issues and PRs on the cfdot GitHub repository linked above. Thanks, Eric, CF Runtime Diego PM |
|
|
|
Incubation Proposal: CredHub (credential manager)
Dan Jahner
Hello Everyone,
Pivotal would like to propose to the Extensions PMC a new incubation project focusing on credential management in Cloud Foundry. This product may be used in a Cloud Foundry environment to centralize and secure credential generation, storage, lifecycle management and access. Project name: CredHub Project proposal: https://docs.google.com/document/d/1iG28J2Lm8RY3BXCZqqNWO7v-G1ppcdK8cizlhbN_o4g/edit?usp=sharing Proposed Project Lead: Dan Jahner (Pivotal) Proposed Scope: See “Proposed Scope” in the proposal Development Operating Model: Pairing Model Technical Approach: See “Basic Architecture” and “BOSH Manifest Implementation” in the proposal Initial team committed: 6 engineers from Pivotal Please let me know if you have any questions. Thanks, Dan Jahner djahner(a)pivotal.io |
|
|
|
Re: Cloud Foundry Diego v1.0.0 released, starting EOL schedule for DEAs
Gwenn Etourneau
Hi Jason,
You can take a look here https://www.cloudfoundry.org/250k-containers-in-production-a-real-test-for-the-real-world/ On Fri, Dec 16, 2016 at 4:47 AM, Jason Huang <jasonxs.huang(a)gmail.com> wrote: Hi Eric, |
|
|
|
Re: CVE-2016-8218: Unauthenticated JWT signing algorithm in routing
Molly Crowther
After some discussion with Shannon, it appears that the affected release
toggle quoted message
Show quoted text
versions in the initial notice were not correct. We have corrected the version numbers in the notice on cloudfoundry.org. The versions vulnerable to this exploit are: - routing-release versions prior to 0.142.0 - cf-release versions 203 to 231 Please review and let us know if you have any questions. Apologies for the confusion. https://www.cloudfoundry.org/cve-2016-8218/ Thanks, Molly Crowther CFF Security Team On Wed, Dec 14, 2016 at 11:14 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
Additional clarification: |
|
|
|
Re: Important: do not use Diego v1.3.0 if you manually set the Diego cells' disk or memory capacity
Eric Malm <emalm@...>
Hi, all,
toggle quoted message
Show quoted text
Diego v1.3.1 is now out with a fix for this regression: https://github. com/cloudfoundry/diego-release/releases/tag/v1.3.1. Apologies again, Eric On Thu, Dec 15, 2016 at 12:16 PM, Eric Malm <emalm(a)pivotal.io> wrote:
Hi, all, |
|
|
|
Important: do not use Diego v1.3.0 if you manually set the Diego cells' disk or memory capacity
Eric Malm <emalm@...>
Hi, all,
If you set the diego.executor.disk_capacity_mb or diego.executor.memory_capacity_mb BOSH properties to numeric values in your Diego manifest, *please do not use Diego v1.3.0*. It contains a configuration regression wherein the cell rep fails to start when these values are numeric. Those values both default to the string value "auto", meaning that the cell auto-configures those capacities based on what its local garden reports them to be. The Diego team will release Diego v1.3.1 as soon as possible with a fix for this regression. We apologize for the inconvenience. Thanks, Eric, CF Runtime Diego PM |
|
|
|
Re: Cloud Foundry Diego v1.0.0 released, starting EOL schedule for DEAs
Jason Huang
Hi Eric,
toggle quoted message
Show quoted text
It's great to see that "The Diego team has succeeded in running 200,000 CF apps with a total of 250,000 instances on a large, Diego-backed CF deployment on GCP.". Do you know how many cells are used in the test and the resource allocation for each of the cells? Thanks, Jason On Tue, Nov 29, 2016 at 9:53 AM, Eric Malm <emalm(a)pivotal.io> wrote:
Hi, all, |
|
|
|
Deprecating the `garden.docker_registry_endpoint` property?
Will Pragnell <wpragnell@...>
Hi all,
We're considering deprecating (sort of, see below) the `garden.default_docker_registry` property, but would like to know if anyone is using it first. When I say deprecating, what I really mean is that we're considering not implementing it or an equivalent for GrootFS, which would mean that this feature would no longer be available when GrootFS ships next year. We think this feature has never worked correctly in the Cloud Foundry deployment case anyway. There's no way to set it for Docker app staging at present, and therefore staging would try to pull container image metadata from a different registry than the one Garden would pull the actual image from if this property is set. If anyone is setting this property in their CF deployment, We'd love to hear about it and understand why. Otherwise, we probably won't implement an equivalent property for GrootFS. Thanks, Will |
|
|