When adding an alarm action with the scheme trust+http:, Aodh allows the user to provide a trust ID to use to acquire a token with which to make the webhook request. (If no trust ID is provided then Aodh creates a trust internally, in which case there is no issue.) However, Aodh makes no attempt to check that the user creating the alarm is the trustor or has the same rights as the trustor - it doesn't even attempt to check that the trust is for the same project as the alarm.
The nature of the trust+http: alarm notifier is that it allows the user to obtain a token given the ID of a trust for which Aodh is the trustee, since the URL is arbitrary and not limited to services in the Keystone catalog.
It is my understanding (though I'm open to correction) that trust IDs are not meant to be secret - i.e. that security should rely on the secrecy of the trustee's credentials, not of the trust ID.
The current setup requires that the security posture be equivalent to, or even stronger than, that for a bearer token, since the trust ID can be used to obtain a token and it may never expire. (The vulnerability is limited to Aodh though, since it only applies to trusts where Aodh is the trustee.) In principle this *could* be a valid choice, although I personally would disagree with it. In practice, that is not the current security posture - for example, trust IDs are stored unencrypted in the database and routinely logged unobfuscated.
The easiest solution would be to simply disallow users supplying their own trust IDs. This may well be feasible - it's likely that in most clouds non-admin users will not have the necessary permissions to get the ID of the Aodh service user, which is required to create a trust with that user as the trustee. Heat does not supply a trust ID in its convenience code for setting up an autoscaling alarm. So there are probably no users of this feature in the wild.
To eliminate the vulnerability without eliminating the feature, I believe Aodh would need to check that the user creating the alarm possesses all of the trust privileges - i.e. their token is for the same project ID and they have all of the roles that the trust does. Or, alternatively, check that the user *is* (i.e. has the same user ID as) the trustor.
I introduced the feature back in the day where it was in ceilometer, and we were not sure whether or not the trust ought to be created by ceilometer. I think it's safe to always create the trust now; I'd be shocked if anyone ever tried to pass a pre-created one.