Security review. This is only the highest level review and was not an in depth code audit.
The two CVEs are already fixed in trusty. CVE-2013-6426 was pretty extensive since it had to implement missing policy enforcement in CFN API. CVE-2013-6428 was much more reasonable. High level review shows that heat is supportable for main.
build_userdata() in ./heat/engine/resources/nova_utils.py is supposed to be used by cloud-init and in part sets up a user using something like this in boothook.sh:
useradd -m <instance_user>
echo -e '<instance_user>\tALL=(ALL)\tNOPASSWD: ALL' >> /etc/sudoers
Updating sudoers in this manner is not ideal. Better for Ubuntu systems is to update a file in /etc/sudoers.d/ (which is supported at least as far back as 12.04 LTS). Is heat on Ubuntu supposed to be capable of orchestrating non-Ubuntu servers? If not, should this be updated to use /etc/sudoers.d/heat-instance-user (or similar)?
Security review. This is only the highest level review and was not an in depth code audit.
The two CVEs are already fixed in trusty. CVE-2013-6426 was pretty extensive since it had to implement missing policy enforcement in CFN API. CVE-2013-6428 was much more reasonable. High level review shows that heat is supportable for main.
build_userdata() in ./heat/ engine/ resources/ nova_utils. py is supposed to be used by cloud-init and in part sets up a user using something like this in boothook.sh: user>\tALL= (ALL)\tNOPASSWD : ALL' >> /etc/sudoers
useradd -m <instance_user>
echo -e '<instance_
Updating sudoers in this manner is not ideal. Better for Ubuntu systems is to update a file in /etc/sudoers.d/ (which is supported at least as far back as 12.04 LTS). Is heat on Ubuntu supposed to be capable of orchestrating non-Ubuntu servers? If not, should this be updated to use /etc/sudoers. d/heat- instance- user (or similar)?