Changes from v0.1453.0 to v0.1454.0
Operators can now install a set of trusted system certificates in the default
/etc/ssl/certs trust store of the cflinuxfs2 rootfs. This is particularly useful if your cflinuxfs2-based instances communicate with external services signed by a custom CA, in which case you can use this feature to install that CA certificate in all the instances.
To install the certificates, supply the contents of the PEM-encoded certificates in the
diego.rootfs_cflinuxfs2.trusted_certs property in the Diego deployment manifest. As with other PEM-encoded manifest data, you may wish to use the YAML
| block-literal syntax to specify the property, as follows:
properties: diego: rootfs_cflinuxfs2: trusted_certs: | -----BEGIN CERTIFICATE----- (cert number 1 data) -----END CERTIFICATE----- # comments outside the PEM boundaries will be ignored -----BEGIN CERTIFICATE----- (cert number 2 data) -----END CERTIFICATE-----
If you are using the spiff-based manifest-generation scripts, this property can also be specified in the property-overrides stub.
- As a CF user, I expect all Tasks and LRPs using the cflinuxfs2 rootfs to contain trusted certificates in their default trust store
- As a CF user, I expect trusted certificates to be available to cflinuxfs2- and Docker-image app instances in a conventional location (in flight)
- investigate whether we can use CF_INSTANCE_PORTS instead of rewriting diego-sshd port arguments
- cloudfoundry-incubator/diego-ssh #17: Rewrite listen address using CF_INSTANCE_PORTS on Windows
- The route-emitter should log and emit metrics if it detects two distinct instances with the same address in its in-memory routing table
- cloudfoundry-incubator/nsync #6: Dont populate cf-routes if CC does not send routes
- developer should be able to verify that when deleting an app or route, it’s route_mappings are also deleted (in flight)
- As a CF+Diego operator, I would like to use the Diego team’s tooling to deploy CF and Diego to an AWS environment
- As a Diego operator, I would like a script to generate a vizzini errand manifest for my Diego deployment
Test Suites and Tooling
- The dusts should work against the latest bosh-lite box.
- cloudfoundry-incubator/diego-release #135: 132 - Verify this repos isn’t a submodule before invoking install-git-hooks
- cloudfoundry-incubator/cf_http #2: Common response generation methods were present throughout Diego.
BOSH job changes
BOSH property changes
diego.rootfs_cflinuxfs2.trusted_certs: Bundle of certificates to install in the cflinuxfs2 rootfs default trust store (
Upload this release version to the Director:
$ bosh upload-release https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1454.0 --sha1 4175435ff2e5c81494a0398f93c53807424edb0c
Modify deployment manifest to use this release in addition to any other used releases:
releases: - name: diego version: "0.1454.0"
Finally add needed deployment jobs and specify values for required properties.
Optionally download sha1: 4175435ff2e5c81494a0398f93c53807424edb0c release tarball locally:
# ...or download it directly using curl $ curl -L -J -O https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1454.0 # or with wget... $ wget --content-disposition https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1454.0