Support configuring networkaddress.cache.ttl easily

[rocketraman]

It would be nice if networkaddress.cache.ttl could easily be specified for jib-based images. Currently the java.security policy file simply contains -1, which is the default behavior (which may be "cache forever" in some cases, and is usually not appropriate especially for cloud environments in which jib-built containers are likely to run).

[mpeddada1]

@rocketraman we want to be careful about the security implications of this but if you want to customize that property then have you tried using the <extraDirectories> feature to load the java.security file with the desired networkaddress.cache.ttl value onto the image. It looks like there is also a JVM parameter -Djava.security.properties that allows overriding the default java.security file which can be helpful to explore.

Additionally, here is a similar example: https://github.com/GoogleContainerTools/jib/issues/2240

[rocketraman]

@rocketraman we want to be careful about the security implications of this

Not sure I understand this. Isn't it better for the default policy to come from upstream, while I customize the minimum necessary?

If I copy the entire policy file in order to customize it, I will miss out on unrelated future upstream fixes or improvements to the policy file.

but if you want to customize that property then have you tried using the <extraDirectories> feature to load the java.security file with the desired networkaddress.cache.ttl value onto the image. It looks like there is also a JVM parameter -Djava.security.properties that allows overriding the default java.security file which can be helpful to explore.

Yes but see above. I don't see how this is better from a security implications perspective.

Additionally, here is a similar example: https://github.com/GoogleContainerTools/jib/issues/2240

[mpeddada1]

Right it makes sense to be as granular as possible. This is only a workaround to set networkaddress.cache.ttl but we can leave this issue open to see if there is more interest from the community.

[cbornet]

we can leave this issue open to see if there is more interest from the community.

👍 There is interest 😃

[JordanBerginSkedulo]

Can confirm, there is most certainly interest here 😂. Before switching over to jib we would make these changes in a dockerfile with RUN commands, so a workaround I'm toying with is simply having a dockerfile based on java vendor of choice, run those commands, publish the image somewhere, and use that as the base image in jib instead?

Will update here about any learnings I find as this issue has only just come to my attention!

Also, jib rocks, thank you very much for it!

[JordanBerginSkedulo]

Edit: To be clear the workaround provided in this comment is reliant on the choice of base image having security.overridePropertiesFile=true already set in the java.security file, so should not be considered fool-proof.

OK so I decided to try your workaround @mpeddada1, and it does seem to work like a charm. @rocketraman please correct me if I'm wrong but I get the impression that the expectation is that -Djava.security.properties would replace the default java.security file in its entirety, so you would lose all the defaults? At least this is how I interpreted the conversation.

I had a read of the comments in the java.security file in a corretto distribution and it explains the following:

If security.overridePropertiesFile=true is set (which for corretto at least it is!), then -Djava.security.properties=<URL> will append properties to the default file, whereas -Djava.security.properties==<URL> (2 equals) overwrites it completely.

So with that, applying the solution of adding a java.security file to main/jib with new properties (in my case, networkaddress.cache.ttl=5), and then adding the following block to my Gradle jib config:

    container {
        jvmFlags = listOf(
            "-Djava.security.properties=/java.security",
            "-Djava.security.debug=properties", //causes application to print out where it pulls security props from, in my case it lists both the default file and my new file
        )
    }

results in the new value being set (verified by calling Security.getProperty in my application). To be extra safe I checked the value of networkaddress.cache.negative.ttl (which I didn't append), and it was still set to 10 (the value in the original security.properties).

I think this means you can keep relying on upstream defaults when you update your base image (i.e. you don't copy the whole file), but keep the ability to customize only the minimum defaults you want in that extra file!

[rocketraman]

@JordanBerginSkedulo Yes, the point isn't that there are workarounds (but thank you for documenting another one [1]). The point is, this is such a common property to set in containers running in the cloud because Java's defaults are often broken (and worse, uncertain -- usually its not even easy to find what the default actually is for a specific JRE implementation). It should therefore be simple to set for a jib user without workarounds. Something like:

container {
  networkaddressCacheTtl = 5
}

[1] I wasn't aware that -Djava.security.properties could append rather than overwrite, but this is still error-prone: some users may try this workaround, not realizing that both security.overridePropertiesFile and policy.allowSystemProperty must be set to true in the policy file before this will work. And it relies on upstream defaults for those values which may change in the future, and vary across openjdk implementations.

[JordanBerginSkedulo]

Yes I absolutely take your point the workaround to append properties depends on something upstream and is therefore unreliable, I'll edit the above comment to emphasise this so as not to mislead people into thinking it's a fool proof workaround.

So is my understanding correct then that the only reliable way to do this is to write to the main java.security file in the base image?

e.g. your code snippet above would append networkaddress.cache.ttl=5 at the end of the file (I'm making an assumption if it's set earlier in the file the last value takes precedence), which should then always work regardless of security.overridePropertiesFile's value?

[rocketraman]

So is my understanding correct then that the only reliable way to do this is to write to the main java.security file in the base image?

I believe that is right.

e.g. your code snippet above would append networkaddress.cache.ttl=5 at the end of the file (I'm making an assumption if it's set earlier in the file the last value takes precedence), which should then always work regardless of security.overridePropertiesFile's value?

Personally, if I were implementing this, I would avoid ambiguity/assumptions here and potential confusion by people viewing or grepping the java.security file inside the container, and have this either modify the value of networkaddress.cache.ttl in the java.security file if it already exists, and append the property if it does not already exist.

[artemptushkin]

+1 to the feature request