[Bug][VIC] Able to Add one VCH to multiple projects in Admiral

[arslanabbasi]

I am able to add One VCH to multiple projects in 1.3.1. This scenario is not supported and users should not be allowed to do this. Screenshots attached below:

Let me know if any additional details are required. Thanks

[martin-borisov]

Which scenario are you referring to?

[stuclem]

If it's not supported to add the same VCH to multiple projects, my concern is that there is no way of knowing in the UI which projects a VCH is assigned to already...

[stuclem]

Also, per https://github.com/vmware/vic-product/issues/1651#issuecomment-386220071, the whitelisting might be problematic if you share a VCH between projects.

So, do we want to recommend against sharing VCHs between projects, even if it is supported?

[stuclem]

@martin-borisov ^^^^

[stuclem]

After looking into how enabling content trust on a project modifies the VCHs that are associated with that project (see #1688), I have doubts about whether adding the same VCH to multiple projects should be supported. It seems to me from the VCH content trust test description that if you add a VCH to a project and enable content trust on that project, the VCH is automatically put into whitelist mode and the VCH can only pull images from that registry, regardless of the settings with which the VCH was deployed.

@martin-borisov, what happens if you add the same VCH to two projects, one that has content trust enabled and one that doesn't?

[stuclem]

@martin-borisov I did a few tests in https://github.com/vmware/vic-product/issues/1688#issuecomment-394741424 by adding a VCH to two projects, with and without CT enabled, and it seems that the CT settings are only applied to the VCH by the first project to which you add the VCH. Any CT settings that you make in the second project are ignored by the VCH, even if CT is disabled on the first project.

So, does this make us want to reappraise the statement that you can add the same VCH to multiple projects? I think that the project-level registry lists also cause problems if a VCH is in more than one project.

[hickeng]

@martin-borisov @stuclem @lazarin It's not actually the first project added - it's the first project the VCH discovers that claims ownership of it. Discovery is prompted by docker info or any of the registry operations (login, pull, et al).

There are two other behaviours we should confirm:

• [ ] does the CT whitelist include only harbor repos configured not to serve unsigned images (as per original CT design and implementation)
• [ ] does the CT whitelist applied to the VCH include all expected harbor repos for the project
• [ ] does the CT checkbox get unchecked and an error returned if admiral cannot confirm that the VCH has successfully picked up the CT whitelist config (this can be seen in the docker info output).

The third case would occur if the whitelist provided when the VCH was deployed is not a superset of the CT whitelist.

[stuclem]

@hickeng when I tested this, only the harbor instance running in the appliance was added to the whitelist. If the project includes other registries that are external to the appliance, they are not added to the whitelist.

[stuclem]

@hickeng I just did another test, for bullets 1 & 2, just to make sure that only the default reg is being added to the VCH whitelist:

1. Deployed VCH without a whitelist: vic-machine-windows create --name vch-ct-test --compute-resource /VSAN-DC/host/VSAN-Cluster --image-store Datastore2 --base-image-size 8GB --volume-store Datastore2:default --bridge-network vic-bridge --bridge-network-range 172.16.0.0/12 --public-network vic-public --tls-cname vch-ct-test --certificate-key-size 2048 --no-tlsverify --user [email protected] --thumbprint 37:B3:E6:5D:EB:AE:6D:E4:25:30:88:39:E2:C3:63:58:C8:8D:5D:1C --target sc-rdops-vm02-dhcp-52-37.eng.vmware.com/VSAN-DC --registry-ca ca.crt --ops-user [email protected] --ops-grant-perms
2. Created a project with 2 registries:
3. Enabled CT on this project.
4. Added the VCH to the project.
5. Ran docker info on the project, and only the default registry is listed:
6. Tried to pull busybox from DockerHub:
7. Tried to provision busybox in management portal:

So, according to your comment above, the behaviour is as it should be, correct?

[stuclem]

@hickeng, regarding your comment "It's not actually the first project added - it's the first project the VCH discovers that claims ownership of it. Discovery is prompted by docker info or any of the registry operations", we now document that you should not add the same VCH to multiple projects (per conversation with @pdaigle). So we don't need to document anything about the order in which VCHs discover projects because there should only be one.