Release v73.0.0 - UAA Release 4.31.0 · cloudfoundry/uaa-release

Breaking Changes

Anyone took a dependency on the past UAA versioning should expect this semver change, as it might break your existing version checks

UAA BOSH Release should stop accepting http traffic from the public

Replaced uaa.port with uaa.locahost_http_port with a default value of 8080, this only allows access to the “healthz” endpoint from localhost
Requires any component communicating with UAA to configure that connection with HTTPS via uaa.ssl.port
- Any value out of [1024-65535] is not allowed and will be rejected
- uaa.port is dropped, and uaa.localhost_http_port is only used for localhost
- Require changing ports and providing UAA’s server cert CA to that component
See change cf-deployment for example

Removes old tls properties uaadb.tls_enabled and uaadb.skip_ssl_validation
Introduces new property uaadb.tls with default enabled
Valid values for uaadb.tls are
- enabled
- enabled_skip_hostname_validation
- enabled_skip_all_validation
- disabled

Anyone who used to deploy UAA without co-locating BPM will see deployment failures after upgrading UAA
Anyone who was already deploying without mentioning bpm.enabled in their manifest (the default was false), or explicitly had bpm.enabled: false, will start using bpm after upgrading.
Anyone who was already deploying with the bosh property bpm.enabled set to true should be unaffected
The bosh property bpm.enabled used to enable BPM will be removed and operators and downstream teams who were using it can remove it from their manifest

UAA no longer loads certificates added to the operating system trust store (i.e. /usr/local/share/ca-certificates) after its pre-start script begins.

Certs added via the BOSH property uaa.ca_certs used to be loaded into the vm's trust store. This no longer happens. They also used to be loaded into the UAA's Java JVM's truststore, which still happens.

Updated configuration variable CLOUD_FOUNDRY_CONFIG_PATH to CLOUDFOUNDRY_CONFIG_PATH.
To provide custom logging configuration, the UAA will still recognize logging.config as a path to a logging configuration file. However, this file must now be Log4j2 format.
The UAA will no longer recognize logging.file or logging.path as valid Log4j2 configuration variables.