Nic, > Will we be enabling developers to store secrets (or secrets setup by their organization) that are loaded by Diego like currently exists only for service bindings? I guess this is already

Will we be making credhub indirectly available to developers so they can populate secret variables for use with their manifest? Currently if a developer wants secrets passed they need to store them

Hi all Currently, the CF ecosystem supports two deployment architectures of Credhub (https://docs.cloudfoundry.org/credhub/#deployment-architecture ): Colocated with BOSH, used for the secrets of

Hi, everyone, Building on the features and technologies the CF Diego and Routing teams have introduced into the CF App Runtime to improve application routing consistency, security, and stability

Hello Karthi, Even we also get rid of all secrets managed in *.yml file and moved all secrets to the vault, and we have the simple jar which embedded into spring/spring boot war. For Example, below

Thank you for confirming me.Can you point me to any examples /links on web of how it could be done in CI like in jenkins world for file creation that you were talking of. Rgds, Karthik.

Hello, The CF container networking team has received feedback from users regarding some pain points around using Application Security Groups (ASGs) for defining egress policies. After much research,

Yes that sounds right - or if you’re deploying in CI then your CI pipeline would create the vars.yml file for each diff target/stage. Nic From: 30111352660n behalf of Sent: Tuesday, July 24, 2018

If the CF CLI doesn't support environment variables, It would be really wonderful if the file would consider environment variables. It would be more in line with the 12 factor manifesto, it would

Hi CF Team, I was exploring on variable substitution in manifest.yml : https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution I see there is a vars.yml that can be used

Thanks for putting the time into another unconference. I'm working on a book about the UAA; hopefully its done by the conf. Since the UAA is delightfully invisible to most people, I'd love to do 5-10

Hi all, We're pleased to confirm that there'll be an Unconference at Basel again this year at 6pm on Tuesday 9th October. We're planning on the same rough schedule as last year, so talks interspersed

We haven't done anything beyond proposing the interface and implementing the option to respect permissions. Since the time of this proposal, BPM has implemented a feature that should allow us to run

Thanks Geoff, Marco, Chip, Jesse, Bernd, and David for sharing your feedback and thoughts. You’ve expressed valid concerns and provided valuable context that I take to heart. I really appreciate the

Another point: most (certainly not all, but most) CVEs are stemcell, buildpack, or rootfs bumps that can be consumed safely/have minimal integration concerns. Even those that are in more substantive

As the previous project lead for RelInt, I want to speak to Marco's concerns directly. We _definitely_ considered the operator as an important persona during any decision-making; if anything, we were

CVE-2018-11047: UAA accepts refresh token as access token on admin endpoints Severity HighVendor Cloud Foundry FoundationAffected Cloud Foundry Products and Versions You are using uaa versions 4.19

I was about to mention that I indeed enjoyed the existing CF model of releases which roughly translated to “you better run fast” for consumers. The thing I found needed some tweaking in the

I don't agree with the claim that we didn't introduce major breaking changes in the past - we did. Routinely. `cf-release` was sem-ver only insofar as every version was a major version. Changes just

Food for thought: One of the challenges here is that maintaining patches for past coordinated releases is expensive (both in time and CI costs). In the CF ecosystem, this has traditionally been the