Hi java buildpacks team, I've been working with a team on implementing Luna HSM support for their large group of apps. The project is using option 3 from the docs ("Buildpack generated configuration if the bound service has both a servers and groups key") and we've run in to a need to change some configuration settings that are in the default configuration and not overrideable through any mechanism.
We have put a chrystoki.conf in resources/luna_security_provider and done a build of the buildpack. This is the "buildpack fork" method - when doing this, and pushing an app and binding it to a "servers" and "groups" containing CUPS, what happens is that the buildpack-generated chrystoki.conf (based on the one put in resources/luna_security_provider) will contain duplicated sections, and only the last section with a given name is used. For example, if Chrystoki.conf contains
VirtualToken = {
VirtualTokenActiveRecovery = activeEnhanced;
...
}
the chrystoki.conf used by the app in the container will have two "VirtualToken" sections, one with the desired settings, and one generated by the service instance, and the former one is ignored and the latter one is used - but that latter one doesn't contain the desired settings.
We understand that the method described above is blending options 3 (generated config) and 2 (buildpack fork) and you're meant to use one or the other, but in this case there are a number of different HSMs and CUPS in a large number of different foundations, and would like to rely on buildpack-generated config to handle that rather than creating and managing a considerable number of handwritten Chrystoki.confs.
We would like to request that the behavior in the above case instead merges buildpack-generated values into an existing Chrystoki.conf if one is present.
Hi java buildpacks team, I've been working with a team on implementing Luna HSM support for their large group of apps. The project is using option 3 from the docs ("Buildpack generated configuration if the bound service has both a servers and groups key") and we've run in to a need to change some configuration settings that are in the default configuration and not overrideable through any mechanism.
We have put a chrystoki.conf in resources/luna_security_provider and done a build of the buildpack. This is the "buildpack fork" method - when doing this, and pushing an app and binding it to a "servers" and "groups" containing CUPS, what happens is that the buildpack-generated chrystoki.conf (based on the one put in resources/luna_security_provider) will contain duplicated sections, and only the last section with a given name is used. For example, if Chrystoki.conf contains VirtualToken = { VirtualTokenActiveRecovery = activeEnhanced; ... }
the chrystoki.conf used by the app in the container will have two "VirtualToken" sections, one with the desired settings, and one generated by the service instance, and the former one is ignored and the latter one is used - but that latter one doesn't contain the desired settings.
We understand that the method described above is blending options 3 (generated config) and 2 (buildpack fork) and you're meant to use one or the other, but in this case there are a number of different HSMs and CUPS in a large number of different foundations, and would like to rely on buildpack-generated config to handle that rather than creating and managing a considerable number of handwritten Chrystoki.confs.
We would like to request that the behavior in the above case instead merges buildpack-generated values into an existing Chrystoki.conf if one is present.