Date   

Re: cf-d 3.0 impact to your CI

Josh Collins
 

Hey Julian,

As you probably know we published cf-deployment 3.0 yesterday and one of the things I'll be doing for future major releases will be to pre-publish information about the contents so folks like you can prepare.

Thanks for your feedback!

Josh (and the rest of the RelInt team)


Windows Server 1709 Stemcells for AWS Available on bosh.io

Kartik Lunkad
 

Hi all,
This is Kartik, PM for the BOSH Windows team that builds and ships Windows stemcells! We are extremely happy to announce that we have published Windows Server 1709 Stemcells for AWS on bosh.io.

This could happen because AWS provided published 1709 AMIs recently that allowed us to build official Windows Server 1709 Stemcells on top of those AMIs. 

Please give it a try and let us know if you have any feedback for us in the #bosh channel on slack! 

Thanks,
---
Kartik Lunkad
Senior Product Manager
Pivotal  :: pivotal.io
email: klunkad@...
mobile: 4129614215


CF-Deployment ALWAYS pulls your latest release from www.bosh.io

Josh Collins
 

Hello Fellow Cloud Foundrians,

You probably already know this but I wanted to send out a quick note on the off chance someone new has joined us.

The Release Integration teams cf-deployment CI pipelines are hooked up to www.bosh.io and will automatically trigger a new build/validation workflow whenever any cf-d component is published to bosh.io. We try to publish cf-deployment releases bi-weekly to get your components out to customers and other cf-deployment developers as soon as possible.

This is wonderful of course.
However, there can be the RARE occasion a component team publishes a new release to bosh.io and then uncovers a significant issue that may not have been caught in acceptance tests due to amount of time or load required for the issue to present itself, or some other condition that's difficult to emulate in dev/testing environments. So it happens sometimes.

In the event that this does happen with a component you're working on (or know about), please take an extra minute to let Release Integration know right away so we can pin our pipelines to the last stable version of your component.

We'd like to publish only the finest and most stable cf-bits for general consumption and thank you for helping us to do just that.

I appreciate that you've read this message!

Cheers,

Josh Collins
PM - Release Integration 
--
Josh Collins
PM - CF R&D Release Integration


Re: cf-d 3.0 impact to your CI

Hjortshoj, Julian <Julian.Hjortshoj@...>
 

We're using the master branch, so we haven't hit this yet, but it sounds like it is coming our way soon.  So...is there a list of breaking changes somewhere that we can refer to in order to prepare ourselves?

Thanks much,
-Julian (and the rest of the persi team)


From: cf-dev@... [cf-dev@...] on behalf of Josh Collins [jcollins@...]
Sent: Thursday, July 26, 2018 8:47 AM
To: cf-dev@...
Subject: [cf-dev] cf-d 3.0 impact to your CI

Hello Folks - 

The cf-deployment 3.0 changes which were checked into our `release-candidate` branch yesterday broke the CI pipelines of several component teams. I wanted to let you know that the @relint-team and I are aware of the impact and are very interested in minimizing such disturbances in the force in the future.

I didn't realize how many teams were consuming the RC branch!!! At any rate, once 3.0 is out the door, I'd like to call a retro discussion and invite any/all folks to discuss how things went and what we can do to make 4.0 moar better. 

Thanks so much, apologies and...Looking forward!

Josh Collins
PM - Release Integration,  Pivotal CF R&D 


cf-d 3.0 impact to your CI

Josh Collins
 

Hello Folks - 

The cf-deployment 3.0 changes which were checked into our `release-candidate` branch yesterday broke the CI pipelines of several component teams. I wanted to let you know that the @relint-team and I are aware of the impact and are very interested in minimizing such disturbances in the force in the future.

I didn't realize how many teams were consuming the RC branch!!! At any rate, once 3.0 is out the door, I'd like to call a retro discussion and invite any/all folks to discuss how things went and what we can do to make 4.0 moar better. 

Thanks so much, apologies and...Looking forward!

Josh Collins
PM - Release Integration,  Pivotal CF R&D 


Re: DNS takeover

adrian.kurt@...
 

Hi Dan

 

Correct, it's exactly that case I'm talking about. If a DNS record pointing to a public CF cloud is not cleaned up properly an attacker can then take over that domain without any issues.

 

My idea would be to add a feature (which can be enabled on public CF offerings) that would verify the ownership of a domain using a TXT record. Of course you don't need that on private CF installations. There this step would be rather annoying.

 

Kind regards

Adrian

 

From: cf-dev@... [mailto:cf-dev@...] On Behalf Of Daniel Mikusa
Sent: Donnerstag, 26. Juli 2018 14:55
To: CF Developers Mailing List <cf-dev@...>
Subject: Re: [cf-dev] DNS takeover

 

I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

 

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

 

Dan

 

 

On Thu, Jul 26, 2018 at 2:23 AM, <adrian.kurt@...> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian

 


Re: DNS takeover

Daniel Mikusa
 

I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

Dan


On Thu, Jul 26, 2018 at 2:23 AM, <adrian.kurt@...> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian



DNS takeover

adrian.kurt@...
 

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian


Re: Add support for multiple Credhubs to CF/Diego

Dr Nic Williams <drnicwilliams@...>
 

To confirm: no better/nicer UX implementation will be provided to developers than for them to author bespoke service brokers to inject secrets into credhub and have client apps have to parse them out of VCAP_SERVICE?

 


From: 30501346560n behalf of
Sent: Thursday, July 26, 2018 3:52 pm
To: cf-dev@...
Cc: emalm@...
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 
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?


-Matthias

2018-07-26 7:48 GMT+02:00 Dr Nic Williams <drnicwilliams@...>:
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 locally/local env vars, and pass them via cf push —var or —var-file.

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?

Nic

 

From: 30111273100n behalf of
Sent: Thursday, July 26, 2018 3:39 pm
To: cf-dev@...
Cc: emalm@...
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 

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 the BOSH director
  • Deployed standalone as its own deployment (“Runtime Credhub”), used for the secrets of service brokers, supported by CF for https://github.com/cloudfoundry-incubator/credhub/blob/master/docs/secure-service-credentials.md to interpolate creds.
    Currently, Diego only supports one credhub endpoint for the Runtime Credhub (which is injected via CloudController in the VCAP_PLATFORM_OPTIONS env var). It does not support multiple Credhubs.

 

However, we have two use cases that would profit if we could add support for CF/Diego so that it can interpolate credentials also from a different credhub url, which could for example be passed as part of the service binding/VCAP_SERVICES.

  • Use case 1: Service brokers running outside of CF:
    Since we use our Service brokers also for other platforms than CF (namely k8s and our IaaS offerings), the service brokers run outside of CF. Thus, they do not use CF’s Runtime Credhub but a dedicated one (since we still want to store the creds securely).
    Thus, CF can’t interpolate the credentials because it can only do this for the Runtime Credhub. If we could pass the SB’s credhub URL as part of the service binding, CF could interpolate the credentials from the 3rd party SB’s credhub.
  • Use case 2: Credhub as a Service: Some customers are asking for a dedicated Credhub instance, since Credhub currently does not offer strong multi-tenancy. So we plan to deploy dedicated Credhubs as a service (pushed as an App to CF).
    CF can also not interpolate the credentials, since it can only do this for the Runtime Credhub – and we could solve that by passing the Credhub URL as part of the service binding, as above.
    We’re aware that Credhub will eventually get stronger multi-tenancy, so Use case 2 might be solved with a shared Credhub (i.e. the Runtime Credhub). However, the need for multiple Credhubs remains with Use case 1.

 

I already reached out on the #credhub Slack (https://cloudfoundry.slack.com/archives/C3EN0BFC0/p1531942967000203) and on the Diego repo (https://github.com/cloudfoundry/diego-release/issues/401).

However, I was told to reach out on a more generic channel since this is a cross-cutting concern.

 

What do you think? Is multiple Credhub something that CF could profit in the future? If yes, we’re happy to provide a PR (see implementation suggestions in the Diego issue).

CCed Erich as the PM of Diego.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd




--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...


Re: Add support for multiple Credhubs to CF/Diego

Matthias Winzeler
 

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?


-Matthias

2018-07-26 7:48 GMT+02:00 Dr Nic Williams <drnicwilliams@...>:

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 locally/local env vars, and pass them via cf push —var or —var-file.

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?

Nic

 

From: 30111273100n behalf of
Sent: Thursday, July 26, 2018 3:39 pm
To: cf-dev@...
Cc: emalm@...
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 

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 the BOSH director
  • Deployed standalone as its own deployment (“Runtime Credhub”), used for the secrets of service brokers, supported by CF for https://github.com/cloudfoundry-incubator/credhub/blob/master/docs/secure-service-credentials.md to interpolate creds.
    Currently, Diego only supports one credhub endpoint for the Runtime Credhub (which is injected via CloudController in the VCAP_PLATFORM_OPTIONS env var). It does not support multiple Credhubs.

 

However, we have two use cases that would profit if we could add support for CF/Diego so that it can interpolate credentials also from a different credhub url, which could for example be passed as part of the service binding/VCAP_SERVICES.

  • Use case 1: Service brokers running outside of CF:
    Since we use our Service brokers also for other platforms than CF (namely k8s and our IaaS offerings), the service brokers run outside of CF. Thus, they do not use CF’s Runtime Credhub but a dedicated one (since we still want to store the creds securely).
    Thus, CF can’t interpolate the credentials because it can only do this for the Runtime Credhub. If we could pass the SB’s credhub URL as part of the service binding, CF could interpolate the credentials from the 3rd party SB’s credhub.
  • Use case 2: Credhub as a Service: Some customers are asking for a dedicated Credhub instance, since Credhub currently does not offer strong multi-tenancy. So we plan to deploy dedicated Credhubs as a service (pushed as an App to CF).
    CF can also not interpolate the credentials, since it can only do this for the Runtime Credhub – and we could solve that by passing the Credhub URL as part of the service binding, as above.
    We’re aware that Credhub will eventually get stronger multi-tenancy, so Use case 2 might be solved with a shared Credhub (i.e. the Runtime Credhub). However, the need for multiple Credhubs remains with Use case 1.

 

I already reached out on the #credhub Slack (https://cloudfoundry.slack.com/archives/C3EN0BFC0/p1531942967000203) and on the Diego repo (https://github.com/cloudfoundry/diego-release/issues/401).

However, I was told to reach out on a more generic channel since this is a cross-cutting concern.

 

What do you think? Is multiple Credhub something that CF could profit in the future? If yes, we’re happy to provide a PR (see implementation suggestions in the Diego issue).

CCed Erich as the PM of Diego.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd




--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...


Re: Add support for multiple Credhubs to CF/Diego

Dr Nic Williams <drnicwilliams@...>
 

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 locally/local env vars, and pass them via cf push —var or —var-file.

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?

Nic

 


From: 30111273100n behalf of
Sent: Thursday, July 26, 2018 3:39 pm
To: cf-dev@...
Cc: emalm@...
Subject: Re: [cf-dev] Add support for multiple Credhubs to CF/Diego
 

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 the BOSH director
  • Deployed standalone as its own deployment (“Runtime Credhub”), used for the secrets of service brokers, supported by CF for https://github.com/cloudfoundry-incubator/credhub/blob/master/docs/secure-service-credentials.md to interpolate creds.
    Currently, Diego only supports one credhub endpoint for the Runtime Credhub (which is injected via CloudController in the VCAP_PLATFORM_OPTIONS env var). It does not support multiple Credhubs.

 

However, we have two use cases that would profit if we could add support for CF/Diego so that it can interpolate credentials also from a different credhub url, which could for example be passed as part of the service binding/VCAP_SERVICES.

  • Use case 1: Service brokers running outside of CF:
    Since we use our Service brokers also for other platforms than CF (namely k8s and our IaaS offerings), the service brokers run outside of CF. Thus, they do not use CF’s Runtime Credhub but a dedicated one (since we still want to store the creds securely).
    Thus, CF can’t interpolate the credentials because it can only do this for the Runtime Credhub. If we could pass the SB’s credhub URL as part of the service binding, CF could interpolate the credentials from the 3rd party SB’s credhub.
  • Use case 2: Credhub as a Service: Some customers are asking for a dedicated Credhub instance, since Credhub currently does not offer strong multi-tenancy. So we plan to deploy dedicated Credhubs as a service (pushed as an App to CF).
    CF can also not interpolate the credentials, since it can only do this for the Runtime Credhub – and we could solve that by passing the Credhub URL as part of the service binding, as above.
    We’re aware that Credhub will eventually get stronger multi-tenancy, so Use case 2 might be solved with a shared Credhub (i.e. the Runtime Credhub). However, the need for multiple Credhubs remains with Use case 1.

 

I already reached out on the #credhub Slack (https://cloudfoundry.slack.com/archives/C3EN0BFC0/p1531942967000203) and on the Diego repo (https://github.com/cloudfoundry/diego-release/issues/401).

However, I was told to reach out on a more generic channel since this is a cross-cutting concern.

 

What do you think? Is multiple Credhub something that CF could profit in the future? If yes, we’re happy to provide a PR (see implementation suggestions in the Diego issue).

CCed Erich as the PM of Diego.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd


Re: Add support for multiple Credhubs to CF/Diego

matthias.winzeler@...
 

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 the BOSH director
  • Deployed standalone as its own deployment (“Runtime Credhub”), used for the secrets of service brokers, supported by CF for https://github.com/cloudfoundry-incubator/credhub/blob/master/docs/secure-service-credentials.md to interpolate creds.
    Currently, Diego only supports one credhub endpoint for the Runtime Credhub (which is injected via CloudController in the VCAP_PLATFORM_OPTIONS env var). It does not support multiple Credhubs.

 

However, we have two use cases that would profit if we could add support for CF/Diego so that it can interpolate credentials also from a different credhub url, which could for example be passed as part of the service binding/VCAP_SERVICES.

  • Use case 1: Service brokers running outside of CF:
    Since we use our Service brokers also for other platforms than CF (namely k8s and our IaaS offerings), the service brokers run outside of CF. Thus, they do not use CF’s Runtime Credhub but a dedicated one (since we still want to store the creds securely).
    Thus, CF can’t interpolate the credentials because it can only do this for the Runtime Credhub. If we could pass the SB’s credhub URL as part of the service binding, CF could interpolate the credentials from the 3rd party SB’s credhub.
  • Use case 2: Credhub as a Service: Some customers are asking for a dedicated Credhub instance, since Credhub currently does not offer strong multi-tenancy. So we plan to deploy dedicated Credhubs as a service (pushed as an App to CF).
    CF can also not interpolate the credentials, since it can only do this for the Runtime Credhub – and we could solve that by passing the Credhub URL as part of the service binding, as above.
    We’re aware that Credhub will eventually get stronger multi-tenancy, so Use case 2 might be solved with a shared Credhub (i.e. the Runtime Credhub). However, the need for multiple Credhubs remains with Use case 1.

 

I already reached out on the #credhub Slack (https://cloudfoundry.slack.com/archives/C3EN0BFC0/p1531942967000203) and on the Diego repo (https://github.com/cloudfoundry/diego-release/issues/401).

However, I was told to reach out on a more generic channel since this is a cross-cutting concern.

 

What do you think? Is multiple Credhub something that CF could profit in the future? If yes, we’re happy to provide a PR (see implementation suggestions in the Diego issue).

CCed Erich as the PM of Diego.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd


Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm <emalm@...>
 

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 (https://lists.cloudfoundry.org/g/cf-dev/topic/11900235#7744, which we have often called "route integrity"), the Diego team intends to make it possible for platform operators to opt into improving the security of how traffic ingresses into application containers. In particular, operators would be able to opt into ensuring that only CF system components, or even only the gorouter HTTP routers, would be able to connect to application containers from the infrastructure-provided network.

The full proposal document is available at https://docs.google.com/document/d/1DjapCLbdgGBmpuWt2P2PV-qm_vUwI_9IZHae9TbN_Pw/edit, and we welcome your comments and questions on the document or on this mailing list thread.

Some areas on which we would particularly like community feedback:

- This secured configuration would initially be incompatible with CF SSH, and would likely never be compatible with TCP routing, as the Routing team has focused its efforts on replacing both the Gorouter and the TCP routers with Istio-configured gateway Envoy proxies. Would those incompatibilities prohibit you as platform operators from opting into this improved security in environments where you would particularly like to enforce it?

- As part of enforcing this more secure configuration, the Diego cell components no longer map ports on their host VM directly to application ports inside the container. Each app instance currently receives the value of its host-side port in its CF_INSTANCE_PORT environment variable, though, and it is also exposed in the response from CC's app stats endpoint. For a variety of reasons (primarily the general availability of container networking and default app-security-group policies), we expect that these values are no longer useful for applications, and so we would like to deprecate them as part of this work and not to supply them in this optional, more secure configuration. Before we do so, we would like to know whether your applications, libraries, or other CF-related tools currently use this information and, if so, to what end.

Thanks,
Eric Malm, for the CF Diego team


Re: Variable Substitution in manifest.yml #

Lingesh Mouleeshwaran
 

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 entry sufficient for any web application in manifest.yml, and we have made it vault orphan token lifetime which having 10 years tenure. 

env:
    JAVA_OPTS:  -Dspring.application.name="<<Vault secret path>>" -Dspring.cloud.vault.token=000-000-00000000-00 


Spring dependency entry :

Below entries required for any web application to embed your vault client jar.

<dependency>
            <groupId>com.config.vault</groupId>
            <artifactId>vault-java</artifactId>
            <version>1.0.0</version>
  </dependency>

<context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            classpath*:/spring-vault-conf.xml  //this file will have details about your propertyplaceholder logic 
        </param-value>
    </context-param>

Your vault client can be the child of class PropertyPlaceholderConfigurer and you can override below method to read from the vault and populate to system ENVs

/**
* {@inheritDoc}
* @throws IOException
*/
protected void loadProperties(Properties properties) throws IOException {
        super.loadProperties(properties.putAll(vaultResource.read()));
}

Hope this gives you some context what you're looking, additional even if go via Jenkins/Travis services, still, secrets are exposed to an environment variable, anyone can able to look the secrets via cf env.

Regards
Lingesh M

On Tue, Jul 24, 2018 at 2:29 PM, <kvemula15@...> wrote:
Hi Nic,
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.



Re: Variable Substitution in manifest.yml #

kvemula15@...
 

Hi Nic,
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.


Feature Narrative - Configure egress policies dynamically

Preethi Varambally
 

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, we have defined a set of short, mid and long term goals to address the issues at hand. 


If you have experience using ASGs and have thoughts on it, please feel free to comment on the doc and perhaps also answer some of the open questions we have at the bottom of the document.



Thank you,

CF Container Networking Team



Re: Variable Substitution in manifest.yml #

Dr Nic Williams <drnicwilliams@...>
 

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 5:36 am
To: cf-dev@...
Subject: Re: [cf-dev] Variable Substitution in manifest.yml #
 
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 discourage people from keeping secrets in `yml` files unencrypted on disk. It would also be easier to use than creating a config file. That way people can source the env variable from features in the CI services like Travis env to encrypt variables, or they could be resolved by looking up the value from something like Hashicorp Vault, all through simple environment variable use. No odd code required to write data to a `.yml` file required. 

On Mon, Jul 23, 2018 at 10:40 AM <kvemula15@...> wrote:
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 to specify the values of app manifest.
Now if i have various environments like Dev, stage , prod for say then do i have to create three different vars.yml files for each environment like var-dev.yml, var-stage.yml and var-prod.yml anr read values from there during cf push?
Appreciate your leads and advice on this.
Rgds,
Karthik.


Re: Variable Substitution in manifest.yml #

Josh Long
 

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 discourage people from keeping secrets in `yml` files unencrypted on disk. It would also be easier to use than creating a config file. That way people can source the env variable from features in the CI services like Travis env to encrypt variables, or they could be resolved by looking up the value from something like Hashicorp Vault, all through simple environment variable use. No odd code required to write data to a `.yml` file required. 


On Mon, Jul 23, 2018 at 10:40 AM <kvemula15@...> wrote:
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 to specify the values of app manifest.
Now if i have various environments like Dev, stage , prod for say then do i have to create three different vars.yml files for each environment like var-dev.yml, var-stage.yml and var-prod.yml anr read values from there during cf push?
Appreciate your leads and advice on this.
Rgds,
Karthik.


Variable Substitution in manifest.yml #

kvemula15@...
 

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 to specify the values of app manifest.
Now if i have various environments like Dev, stage , prod for say then do i have to create three different vars.yml files for each environment like var-dev.yml, var-stage.yml and var-prod.yml anr read values from there during cf push?
Appreciate your leads and advice on this.
Rgds,
Karthik.


Re: Unconference at CF Summit Basel 2018

Dr Nic Williams <drnicwilliams@...>
 

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 mins intro on why its interesting, how to deploy, and how to learn more.

Nic

On Mon, Jul 23, 2018 at 9:36 PM Daniel Jones <daniel.jones@...> wrote:
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 with open space sessions, topped off by something fun at the end. Oh, plus free food and beer.

Things we need from y'all:
  • Talks! We'd love for you folks to present, ideally for <= 10 minutes.
  • Suggestions! Would you like to do another pub quiz? Do you have any other ideas?
  • Sign-ups! If you're coming, please sign up so we know how much food and drink to order.

If you'd like to give a talk, please reply to me, Sara Lenz and Ivana Scott (CC'd).

Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than Cloud Foundry specialists



--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic

1201 - 1220 of 9378