The default security group is created lazily the first time it is requested via a GET. However, this functionality is dependent upon pulling the tenant_id from the token.
This means that an admin user cannot get or create the default security group for arbitrary tenant X. Attempting to do something like GET /security-groups?tenant_id=X yields an empty result. And attempting to create the default group via POST /security-groups {'name': 'default'} results in a 409 even though the default security group does not actually exist.
Note that if an admin user creates a non-default security group for an arbitrary project (ie any security group where the name is not 'default'), the default security group will be created as a side affect.
Another side effect of this lazy creation is that when an admin user is attempting to get security groups for another project (via GET security-groups?tenant_id=X), the default security group may be created for the admin project (because it is tenant that is acutally scoped in the token).
Warning, personal opinion below:
Generally speaking, I think the lazy and silent creation of the default security group causes a lot of problems for the integrity of the API. Now a GET is creating something (and thus is technically no longer idempotent) and a POST to create an arbitrary security group may also silently create the default security group.
Hi Aniruddha, do you work on this bug? If you don't mind I'd like to volunteer to sort this out.