Juju charm security
Discuss ways to improve charm security and security processes.
Blueprint information
- Status:
- Not started
- Approver:
- Jamie Strandboge
- Priority:
- Essential
- Drafter:
- Jamie Strandboge
- Direction:
- Approved
- Assignee:
- Jamie Strandboge
- Definition:
- Approved
- Series goal:
- Accepted for raring
- Implementation:
-
Unknown
- Milestone target:
-
ubuntu-13.04
- Started by
- Completed by
Whiteboard
Charm security and update process
* Juju features to watch:
- Adding arbitrary actions (for applying security updates)
- "security" tagged bugs in juju and juju-core launchpad project
* Ideas for improvement:
- Review points for preventing security bugs
- Static analysis for preventing security bugs (charm proof)
- Better tools and docs for applying apparmor
Charms with AppArmor
* what is the current statue?
* what could be done better?
* would it help if the security team could produce a representative charm or two for charming with apparmor?
* unattended-upgrades charm?
From etherpad (http://
example: http://
juju/security tag: https:/
Charm security and update process
* Juju features to watch:
- Adding arbitrary actions (for applying security updates) - this is for updating deployed software (not the charm itself)
- "security" tagged bugs in juju and juju-core launchpad project
* Ideas for improvement:
- Review points for preventing security bugs
- Static analysis for preventing security bugs (charm proof)
* charm proof captures known problems
* it could have a pedantic mode that warns for red flags
- Better tools and docs for applying apparmor
* currently people aren't doing this
* juju team is pushing for more knowledge
Charms with AppArmor
* what is the current status?
* what could be done better?
* would it help if the security team could produce a representative charm or two for charming with apparmor?
* unattended-upgrades charm?
* Juju bootstrap should generate ssh host keys locally, push them to the instances, load them automatically into a local known_hosts.juju file, and prune them on destroying the environment
- juju team has a plan (needs to be in core), but needs time to do it
- a branch is available
* Juju should inject a random seed via metadata for each instance launched
Possible demo charms:
* unattended-upgrades
* samba
* backend/
Unassigned work items:
[charmers] some sort of command for 'are there upgrades available for this charm' (over the charms in an environment)
[security] maybe demo charm for samba?
[] recover ssh key handling from bitrot, attach it to a bug lp:~jimbaker/juju/ssh-known_hosts; https:/
[security] comment on bug for ssh key handling
[] push high entropy seed from client as part of cloud-init medata
Work Items
Work items:
[seth-arnold] unattended upgrades charm (essential) (2): DONE
[jorge] formally document juju/charms security process: TODO
[jdstrand] review process and review the security notices page (essential) (1): POSTPONED
[jdstrand] discuss charm proof additions (essential) (3) : POSTPONED
[jdstrand] get information to the juju team on how to use AppArmor (essential) (2): POSTPONED
[jdstrand] charm for moin (essential) (3): POSTPONED
[sbeattie] look at apache non-prefork (essential) (1): POSTPONED
[seth-arnold] charm for samba (essential) (5): POSTPONED
[seth-arnold] charm for backend/
[seth-arnold] review juju.ubuntu.
