Re: the patch - Although I agree it fixes the problem I'm not sure its the way we should do it.
We already have a policy "compute_extension:security_groups" which is used by the Nova API to enforce
access in a general way to all of these features. So I'm thinking that rather than introducing new policies
more specific such as compute:security_groups:remove_rules settings to fix the bug we should just use
the existing generic compute_extension:security_groups rule in the ec2 API.
Now I think there may be a reasonable argument for having per method type policy settings in the API
rather than general ones and we have generally been moving this way anyway, but if we do so we need to
be consistent across the Nova and EC2 APIs. So if a compute:security_groups:remove_rules policy is used
by the EC2 code it should also be checked by the Nova API code too. Otherwise deployers could be mislead into
thinking the policy is affecting the Nova API when it isn't.
I think unless there is a clear need now to have detailed policy checks I think for an immediate bug fix we
should just use the existing general security groups policy (which I think also means no policy file changes
are needed by deployers just the code update). And then if we want to have more fine grained policy checks
we can do this in Juno. And this needs to be done fairly carefully for the Nova API side to ensure minimal
upgrade impact.
And more generally we definitely need to ensure all possibly policy checks are in the policy file rather than
rely on defaults as deployers should not be expected to grep the code to see what switches are available :-) I will
submit a blueprint for that work in Juno.
+1 on the impact description
Re: the patch - Although I agree it fixes the problem I'm not sure its the way we should do it.
We already have a policy "compute_ extension: security_ groups" which is used by the Nova API to enforce security_ groups: remove_ rules settings to fix the bug we should just use extension: security_ groups rule in the ec2 API.
access in a general way to all of these features. So I'm thinking that rather than introducing new policies
more specific such as compute:
the existing generic compute_
Now I think there may be a reasonable argument for having per method type policy settings in the API security_ groups: remove_ rules policy is used
rather than general ones and we have generally been moving this way anyway, but if we do so we need to
be consistent across the Nova and EC2 APIs. So if a compute:
by the EC2 code it should also be checked by the Nova API code too. Otherwise deployers could be mislead into
thinking the policy is affecting the Nova API when it isn't.
I think unless there is a clear need now to have detailed policy checks I think for an immediate bug fix we
should just use the existing general security groups policy (which I think also means no policy file changes
are needed by deployers just the code update). And then if we want to have more fine grained policy checks
we can do this in Juno. And this needs to be done fairly carefully for the Nova API side to ensure minimal
upgrade impact.
And more generally we definitely need to ensure all possibly policy checks are in the policy file rather than
rely on defaults as deployers should not be expected to grep the code to see what switches are available :-) I will
submit a blueprint for that work in Juno.