WaitCondition notification breaks in-instance credentials

Since https://review.openstack.org/#/c/23156/ got merged, we have a problem where after a WaitCondition notification happens, we break the /etc/cfn/cfn-credentials file contents

This happens because the keystone user associated with the WaitCondition doesn't have permission to read the secret key of the user associated with the cfn-credentials file

So e.g in the the nested loadbalancer resource template, the Fn::GetAtt CfnLBAccessKey resolves to the error value of "000-000-000", so after the next cfn-hup all communication from inside the instance is broken permanently.

I'm not sure of the best way to fix this yet - possible options:

1 - Store the secret key in our DB (e.g encoded as part of the logical resource ID for the AccessKey resource), this is what I was trying to avoid with the current AccessKey implementation, so I'm not keen on this, and has the added disadvantage that it opens up access to the secret key to any user who has access to the stack (whereas currently only admin users or the actual in-instance user can read it)

2 - Use the stored admin context to refresh the per-resource metadata after the WaitCondition notification arrives (the new refresh logic in service.py::metadata_update()) - I guess this is the way to go, but it doesn't seem that nice to allow the (deliberately unprivileged) WaitCondition user to trigger actions in the admin context.

Any other ideas?