Adding missing KVM mappings
Testing Done:
Local testing with removing CentOS mapping and launch a VM.
Signed-off-by: Nitin Mehta <nitin.mehta@citrix.com>
Local env
1. Create user defined mapping
2. Delete / modify user defined mapping. Should pass
3. Delete / modify system defined mapping. Should fail
Signed off by :- Nitin Mehta<nitin.mehta@citrix.com>
This restriction was purposely avoid confusion of VPN setup, but later found too
strictly and cause troubles for deployment. Removed after testing one customer
gateway with multiple connections.
This patch is for KVM
1. Local testing on KVM
2. Successfully got up system VMs
3. Successfully created a CentOS VM
4. Snapshots are not supported for KVM
Signed off by :- Nitin Mehta<nitin.mehta@citrix.com>
getting applied when a tier in VPC is created.
fix ensures, VpcRoutingPolicyUpdate is send when network rules are
programmed when network tier in VPC is created
the provider only if at least one capability is specified
Fix avoids the check, and only if the createNetworkOffering
'StrechedL2'Subnet' capability is specified then it should match against
'Connectivity' service provider
Changes:
- CS 4.3 handled Network entity in two ways:
a) Specified "UseNetwork" access and did a strict check w.r.t who can use this network. Regular users and Domain Admin went through the strict check. Root admin got access always.
b) Specified "null" access and that meant admins can access this network for the calling API that passes null access.
- Fixing CS 4.4 IAM to handle this behavior:
a) "UseNetwork" is mapped to "UseEntry" and IAM check will be done only for domain admin and regular users when this access is specified. Root Admin is grated access.
b) If "null" access is specified, root and domain admin both are granted access. Regular users still go through IAM.
Changes:
- IAM was applying ordering on accessTypes. Thus if an account had Operate, he got USe access as well. So even if IAM schema did not have 'UseEntry" permission for IpAddress, some other 'OperateEntry' permission on IpAddress was letting this operation go through.
- Fixed IAM to NOT do ordering of access types anymore. IAm will perform strict accessType check only.
- This fix is needed so that admin does not get permission to USE resources from other account just becase he has OPERATE access on those resources due to some other APIs.
- However due to this fix, we break backwards compatibilty with CS 4.3.
- CS 4.3 allowed root admin to do the createPF operation for a user by passing in networkId of the user.
- Same was the case for domain admins within their domains
- Why this worked was due to CS 4.3 simply returning true for root admin/domain admin
- So to maintain backwards compatibilty, we are adding the logic to return "true" for root admin and domain admin just like CS 4.3.
- Exception is: For Network, AffinityGroup and Templates, we still call IAM even for root admin/domain admin, since thats what CS 4.3 did. Just for these 3 resource_types, it used to perform access checks even for root admin/domain admin.
affinity groups available for regular users by passing account and
domainId paramater. This is to revert IAM way of implementing
listAffinityGroupsCmd, will bring it back when we have implemented real
impersonation.