|
Missing az_attr claim in access_token of password grant
Paul Bakare
Hi, An access_token gotten from password grant doesn't contain az_attr when decoded [1]. Is this by design? Is there something I'm doing wrongly? How do I access an access_token additional information (az_attr) when decoded? Kindly advise. Many thanks Odeyemi 'Kayode O. http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde |
||
|
|
||
|
bosh and cf ssl cert update question
강경원 <kyungwon.kang@...>
Hello.
I created CERTS file with bosh-cli with var-store. By default, ssl will be expired after 1 year from generated day. Is there a best way to update ssl at bosh and cf?
|
||
|
|
||
|
Re: Headless browser support in nodejs-buildpack
Franks, Geoff
We had to solve a similar problem ourselves. We ended up building a custom stack for this, forking cflinuxfs2, and adding the additional packages + business logic on top. There are a number of buildpacks that may have issues with stacks not named `cflinuxfs2`, but the only buildpack we needed seemed to work with the custom name, so we have a default stack, and a custom stack for the apps that neeed Chrome. If you can support multi-buildpack pushes with the v3 API, you may be able to make use of that with https://github.com/cloudfoundry/apt-buildpack which would be less long-term maintenance + support compared to forking things.
From: <cf-dev@...> on behalf of "Pietsch, Mathias (Allianz Deutschland, externer Mitarbeiter)" <EXTERN.PIETSCH_MATHIAS@...>
Hello Cloudfoundry-Support team,
in our project we have the following issue:
we would like to generate a PDF-File with screenshots of our angular-html application. Therefore we need a buildpack with a headless browser support.
We already tried to generate screenshots with headless-chrome and phantomjs with the standard nodejs-buildpack. For the headless-chrome we received an error-message that the shared library libnss3.so is missing. The phantomjs process terminated immediately.
Do you have a solution for us to solve our problem? This would be very helpful for finishing our project.
Thank in advance and best regards.
Mathias Pietsch
dienstleistend für Allianz Deutschland AG, Grafische Oberflächen für ROPO Externer Brückenkopf: Darko Pelikan
Erreichbarkeit während des Projekts: Telefon: +49 (0) 711 6 63 - 1537 E-Mail: EXTERN.PIETSCH_MATHIAS@...
------------------------------------------------------------------
Telefon: +49 (0) 711 6 63 - 1537 E-Mail: Mathias.Pietsch@...
Schwalbenrainweg 24 D-63741 Aschaffenburg
PASS IT-Consulting Dipl.-Inf. G. Rienecker GmbH & Co. KG, Handelsregister: Amtsgericht Aschaffenburg HRA 2921, Sitz der Gesellschaft: Aschaffenburg, Komplementärin: Rienecker Beteiligungs-GmbH, Handelsregister: Amtsgericht Aschaffenburg HRB 7619, Sitz der Gesellschaft: Aschaffenburg, Geschäftsführer: Dipl. Inf. Gerhard Rienecker
|
||
|
|
||
|
Re: Write custom MFA connector/provider
Sree Tummidi
Hi Rashmi, We only have support for google authenticator at this time. The best way to integrate an existing MFA to UAA is through federation like SAML/OIDC. In this case the entire auth flow is delegated to the external provider. Thanks, Sree TummidiSr. Manager, Product Management Pivotal Cloud Foundry On Thu, Jul 26, 2018 at 1:44 PM, Rashmi Singh <singhrasster@...> wrote:
|
||
|
|
||
|
Write custom MFA connector/provider
Rashmi Singh <singhrasster@...>
Hello, I was looking at the MFA Providers and it looks like currently only Google authenticator is supported. I need an MFA support but not Google authenticator. Is it possible to write a custom authenticator /MFA connector on UAA that we can then integrate with our TokenValidator? We have our own Authentication server that supports different types of authentication like OTP, grid based, etc and we would like to integrate UAA with that. What would be preferred is that we do the normal username/password authentication on UAA and then for the second factor, instead of using Google Authenticator, we have our custom provider/connector that we can integrate with our token validator/server for authentication. Is it possible to make changes in the UAA code and write a provider to achieve this? |
||
|
|
||
|
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 ):
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.
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 ___________________________________________________________________________ matthias.winzeler@... |
||
|
|
||
|
Headless browser support in nodejs-buildpack
Pietsch, Mathias (Allianz Deutschland, externer Mitarbeiter) <EXTERN.PIETSCH_MATHIAS@...>
Hello Cloudfoundry-Support team,
in our project we have the following issue:
we would like to generate a PDF-File with screenshots of our angular-html application. Therefore we need a buildpack with a headless browser support.
We already tried to generate screenshots with headless-chrome and phantomjs with the standard nodejs-buildpack. For the headless-chrome we received an error-message that the shared library libnss3.so is missing. The phantomjs process terminated immediately.
Do you have a solution for us to solve our problem? This would be very helpful for finishing our project.
Thank in advance and best regards.
Mathias Pietsch
dienstleistend für Allianz Deutschland AG, Grafische Oberflächen für ROPO Externer Brückenkopf: Darko Pelikan
Erreichbarkeit während des Projekts: Telefon: +49 (0) 711 6 63 - 1537 E-Mail: EXTERN.PIETSCH_MATHIAS@...
------------------------------------------------------------------
Telefon: +49 (0) 711 6 63 - 1537 E-Mail: Mathias.Pietsch@...
Schwalbenrainweg 24 D-63741 Aschaffenburg
PASS IT-Consulting Dipl.-Inf. G. Rienecker GmbH & Co. KG, Handelsregister: Amtsgericht Aschaffenburg HRA 2921, Sitz der Gesellschaft: Aschaffenburg, Komplementärin: Rienecker Beteiligungs-GmbH, Handelsregister: Amtsgericht Aschaffenburg HRB 7619, Sitz der Gesellschaft: Aschaffenburg, Geschäftsführer: Dipl. Inf. Gerhard Rienecker
|
||
|
|
||
|
Re: cf-acceptance-tests moving to development/master --> PR into develop please :)
Iryna Shustava
Hey all, We just created develop and RC branches in the CATs repository. Please make all pull requests on develop going forward. Thanks! Sebastian Vidrio & Iryna Shustava CF Release Integration Team On Fri, Jul 27, 2018 at 1:14 PM Josh Collins <jcollins@...> wrote:
|
||
|
|
||
|
Re: Deprecate route-sync from CFCR to CFAR
Hi
Oleksandr
and Shannon, I wonder what's the current plan for routing to CFCR workloads from CFAR ? Is there a concensus towards the proposed usage of TCP router [1] with an associated
CloudFoundryRouteController component, or rather leverage K8S cloud providers ?Which team would be working on this as I could not yet find related stories in the routing/tcp-routing/kubo pivotal trackers [2][3][4] Thanks in advance, Guillaume. On Mon, Jul 16, 2018 at 12:57 PM, Oleksandr Slynko <oslynko@...> wrote:
|
||
|
|
||
|
Re: cf-deployment 3.0
Marco Voelz
Dear Josh, dear David,
Thanks David for sharing your past experiences in the RelInt team. I can sympathize with the stories you shared and understand the motivation for the planned changes better.
Now that cf-deployment 3.0 is there, let me tell you "how it went": It now means you have to switch to bosh-dns to receive security updates.
There is a number of reasons why we didn't introduce bosh-dns yet in our production system:
Moreover, I think although everyone knew that bosh-dns was going to be a requirement at some point in time, the fact that this would be 3.0 was poorly communicated (I might have missed a mail there, but I cannot remember this. I would have raised my concerns
earlier if that would have been the case).
For our production environment, we now have a few choices, all of them bring me headaches:
All of this brings me back to: As someone responsible for a cf-deployment production environment, I find it incredibly difficult having to deal with breaking changes like this on a regular basis to get security fixes.
Warm regards
Marco
From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Wednesday, July 18, 2018 11:54:06 PM To: cf-dev@... Subject: Re: [cf-dev] cf-deployment 3.0 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 time and effort required for meaningful dialogue about the impacts of the proposed release cadence. While the RelInt team's primary goal remains supporting the CF Foundation engineering teams and their ability to validate their commits in CI, your points underscore a tension we’re acutely aware of. We’re trying to meet the needs of both the CFF Contributor and Operator and the ‘trick’ is to find a sustainable balance between the two. However, on occasions where we must prioritize one over the other we’re going to favor the CFF Contributor. I mentioned this earlier, but it’s worth restating that the RelInt team doesn’t have any plans provide LTS support and as Chip and Jesse pointed out that has traditionally been a value-added service provided by commercial vendors. In the spirit of iteration, I’d like to propose we proceed with the release cadence I originally outlined and see how it goes. Again, thank you for providing such valuable feedback. Cheers, Josh Collins _Current_ PM of
CF Release Integration
|
||
|
|
||
|
Re: DNS takeover
Maybe a hint similar to what DNS providers gave to to DNS zone records owners in the blog you referenced (see image copied below) could be added to CF CLI cf delete-domain confirmation prompt  such as "If you want to use this domain within CF in the future, we recommend that you either keep this domain, or update DNS entry, in order to avoid HTTP requests to be misrouted in the future if someone else creates a domain with the same name.
Really delete domain X? " Guillaume. On Thu, Jul 26, 2018 at 4:40 PM, <adrian.kurt@...> wrote:
|
||
|
|
||
|
Re: cf-d 3.0 impact to your CI
Josh Collins
I mentioned I'd call a retro to discuss how things went and what we can do to make the transition to cf-d 4.0 better and wanted to follow up with details.
When: Wednesday August 1st @ 11am PST Where: Pivotal SF, Andromeda conference room or Zoom: https://pivotal.zoom.us/my/relint Retro Board: https://retros.cfapps.io/retros/cf-rel-int I look forward to it! Josh Collins PM - Release Integration |
||
|
|
||
|
Variable susbtitution in manifest.yml in jenkins job
#cf
kvemula15@...
Hi All,
I'm trying to get some examples to do variable substitution in App manifest.yml files which replaces the manifest inheritance feature (https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#variable-substitution). And how this could be done in a jenkins job. I would appreciate any suggestions on it. Regards, Karthik. |
||
|
|
||
|
cf-acceptance-tests moving to development/master --> PR into develop please :)
Josh Collins
Hello (again) My Cloud Foundrians, -- Some changes are coming soon that are likely to impact you and I wanted to give you a heads up in advance... RelInt has kicked off a tract of work to improve the acceptance test suite that's run by (hopefully) all component teams before they cut releases for integration to cf-deployment. Cf-acceptance-tests a.k.a. CATs are going to get a iterative makeover. CATs changes are likely to be released in fits and starts because of the RelInt team's distributed focus across marshalling PR's from component teams and continual fixing of broken builds as changes come into our pipelines, but please know we are focusing a portion of our attention on CATs because we care. Making irregular, and possibly dramatic, changes to the CATs suite could have negative impacts for all of us, so before we really get into things we're making some changes:
We're just about to make the switch over to develop/master so I wanted to give you a heads up so you'll know to submit PR's to the develop branch soon rather than master. ************************************ We'll focus initially on making improvements aimed at:
Subsequent improvement steps will be based on learnings from executing on the above and talking to CATs consumers, like you. *********************************** I'll send another note when we've officially made the switch to develop. 'Till then, keep submitting PRs to master. If you have any questions, concerns, or suggestions related to CATs, please don't hesitate to reach out to @jcollins or @relint-team ion the cats-users slack. We're always interested in what you have to say. Thanks very much! Josh Collins PM - Release Integration Josh Collins PM - CF R&D Release Integration |
||
|
|
||
|
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 |
||
|
|
||
|
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:
|
||
|
|
