Required credentials are missing when heat-engine calls heatclient operations
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Fix Released
|
Medium
|
Steve Baker |
Bug Description
While adopting the latest from the software configurations in Icehouse, we discovered an issue with the new software configuration type and its assumptions about using the heat client to perform behavior.
The change was introduced in:
commit 21f60b155e4b653
Author: Steve Baker <email address hidden>
Change: https:/
The net is that the software config type in software_config.py lines 147-152 relies on the heat client to create/clone software configuration resources in the heat database:
def handle_
props = dict(self.
sc = self.heat(
My concerns with this approach:
When used in standalone mode, the Heat engine receives headers which are used to drive authentication (X-Auth-Url, X-Auth-User, X-Auth-Key, ..):
curl -i -X POST -H 'X-Auth-Key: password' -H 'Accept: application/json' -H 'Content-Type: application/json' -H 'X-Auth-Url: http://[host]:5000/v2.0' -H 'X-Auth-User: admin' -H 'User-Agent: python-heatclient' -d '{...}' http://
In this mode, the heat config file indicates standalone mode and can also indicate multicloud support:
# /etc/heat/heat.conf
[paste_deploy]
flavor = standalone
[auth_password]
allowed_auth_uris = http://[host1]:5000/v2.0,http://[host2]:5000/v2.0
multi_cloud = true
Any keystone URL which is referenced is unaware of the orchestration engine which is interacting with it. Herein lies the design flaw.
Further, at this point, the username and password are null, and when the auth_password standza is applied in the config file, Heat will deny any attempts at authorization which only provide a token. As I understand it today, that's because it doesn't have individual keystone admin users for all remote keystone services in the list of allowed_auth_urls. Hence, if only provided with a token, I don't think the heat engine can validate the token against the remote keystone.
One workaround that I've implemented locally is to change the logic to check for standalone mode and send the username and password.
flavor = 'default'
try:
flavor = cfg.CONF.
except cfg.NoSuchOptError as nsoe:
flavor = 'default'
# We really should examine the pipeline to determine whether we're using authtoken or authpassword.
if flavor == 'standalone':
if 'username' in context_map.keys():
else:
if 'password' in context_map.keys():
else:
args = {
}
else:
if self.auth_token is None:
...
Responses from Steve Baker from the mailing list:
If you look at self._get_
This is a great summary of the problem, but it really belongs in a launchpad bug. Lets discuss potential solutions there.
summary: |
- Software configuration breaks OpenStack Heat standalone mode + Required credentials are missing when heat-engine calls heatclient + operations |
Changed in heat: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → juno-1 |
Changed in heat: | |
milestone: | juno-1 → juno-2 |
Changed in heat: | |
assignee: | nobody → Steve Baker (steve-stevebaker) |
Changed in heat: | |
importance: | High → Medium |
Changed in heat: | |
milestone: | juno-3 → juno-rc1 |
Changed in heat: | |
status: | Triaged → In Progress |
Changed in heat: | |
status: | Fix Committed → Fix Released |
Changed in heat: | |
milestone: | juno-rc1 → 2014.2 |
I think the solution here would be for KeystonePasswor dAuthProtocol to set a header like HTTP_X_ AUTH_METHOD= 'authpassword' , and RequestContext to store this in an auth_method attribute. Then the heat() method can include the credentials if auth_method= ='authpassword'
Feel free to assign this bug to yourself if you intend to submit a patch to fix this.