Hi everyone, below you can find the updates from the Canonical Juju Team for the week starting on the 02/08/2021. Have a great weekend!
1 Like
G’Day Juju
This week:
1 Like
-
Fixed data race in
worker/caasunitprovisioner:TestV2CharmExitsApplicationWorker - Reading the
lxd execcode in detail to determine how it works and what we can reuse. - Wrote a doc describing why I don’t think it’s feasible to create a shared “remote exec” library for LXD + Pebble (though we can probably share the websocket proxying utilities).
- Started hacking the
lxc execcode into Pebble shape.
1 Like
- 2.9.10 release
- Add
impishsupport to juju client - Fix issue with
juju show-unitprinting the wrong application relation data -
Fix
retry-provisioningcommand - Ensure Juju controller recovers when mongo is updated underneath it
- More work on secrets spec
- Prototype secrets POC using a Hashicorp Vault backend store with 2 charms exchanging a secret via relation data
2 Likes
- Investigation and API change for the pubsub client, where it’s possible to leak goroutines in some scenarios. #12
- Implement/expose pubsub metrics for subscribers and publishers. More work is required to push this out into Juju. #13
- Refactor the raft lease clock on the leader, rather than broadcasting the advancing of the clock over pubsub. #13203
- Investigative work into removing raft lease requests over pubsub and favour direct API requests. Preliminary work to abstract the pubsub requests out of the store directly can be found at #13223
1 Like
I was working on the private docker registry and non dockerhub registry(gcr, car, quay.io, etc) support(then I was sick for almost 3 days)
1 Like
Tell us more about this secrets thing…
TL;DR;
Juju currently doesn’t explicitly model the concept of secrets. Thus when a charm needs to be configured to use a credential or token of some sort to gain authenticated access to a restricted API, the secret is passed in directly without any obfuscation or disclosure protection. This also applies to inter-charm exchange of data via relations. The net effect is that Juju has no way to maintain the integrity of workload secrets; these are exposed in various ways, including log lines, reading charm configuration, dumping relation data bags etc.
Another consideration is that government regulatory and/or customer compliance requirements for management of sensitive digital assets (eg GDPR, SOX etc) will mandate that certain practices be followed regarding the storage and controlled access to sensitive digital assets such as secrets. A requirement is often that trusted and/or standards compliant secret access stores or workflows be used; Juju will need to integrate with these as well as providing a fallback implementation for development or other less stringent deployment scenarios.
In summary, Juju will be gaining a mechanism to enforce access to secrets:
- secure storage, provisioning and management of secrets such as passwords, encryption keys and X.509 certificates
- the ability for charms to exchange references to secrets
- the ability for devops to configure charms to use specified secrets
When dumping charm config or relation data, you’ll now see a reference to a secret (eg secret://mariadb.password) rather than the secret itself. The charm needing to use the secret will ask Juju to provide the value, and Juju mediates access based on permissions granted by the entity which created the secret originally. We’ll initially provide a Juju secrets store in mongo, as well as integration with k8s secrets and Vault.
7 Likes
- Use a key-based mutex lock to download resources/agent bins once. LP1905703 #13215
- Partial Work: Add pebble replan, support serverside restart. operator#580
1 Like
Whats the progress on this so far? Very keen to see this and start working with it.