All Posts

Hi Miguel, we plan to introduce encryption of named disks and VM templates as part of the official (GA) release of BYOE solution. Both will be encrypted the same way as regular VMs with the exception that deep re-encrypt will not be supported in the GA release. Please let us know if this behavior would cover your use cases?

Hi @m1gu3l and thanks for your question! Yes, you are right with your observation that with the tech preview only shallow re-encrypt is performed. We are planning to introduce Deep Re-encrypt on a per VM basis. The operation will have a number of prerequisites which come from vCenter: the VM needs to be powered off and it must not have snapshots. We plan to introduce this feature either with the GA or with one of the first BYOE releases afterwards. Please confirm what is importance of this use case for you? -Radostin

Hello and thanks for your question! Yes, you are right with your observation that with the tech preview only shallow re-encrypt is performed. We are planning to introduce Deep Re-encrypt on a per VM basis. The operation will have a number of prerequisites which come from vCenter: the VM needs to be powered off and it must not have snapshots. We plan to introduce this feature either with the GA or with one of the first BYOE releases afterwards. Please confirm what is importance of this use case for you? -Radostin

Hi @m1gu3l and thanks for your question! Yes, you are right with your observation that with the tech preview only shallow re-encrypt is performed. We are planning to introduce Deep Re-encrypt on a per VM basis. The operation will have a number of prerequisites which come from vCenter: the VM needs to be powered off and it must not have snapshots. We plan to introduce this feature either with the GA or with one of the first BYOE releases afterwards. Please confirm what is importance of this use case for you? -Radostin

Hi @m1gu3l and thanks for your question! Yes, you are right with your observation that with the tech preview only shallow encryption is being performed. We are planning to introduce Deep Encrypt on a per-VM basis. It will have a number of requirements which come from vCenter: the VM needs to be powered off and it must not have snapshots in order to be able to perform the action. We are planning to introduce this feature either with the GA or one of the very first releases afterwards. Can you please confirm what is the importance of this feature for you? -Radostin

We've been looking into this and can confirm you will be able to use roles other than 'tmc:admin' or 'tmc:member' to give access to specific resources. I believe this scenario would've worked if you had added the 'Organization Administrator' group to the 'organization.credential.view' role binding or some other 'organization.*' role. Please try this after we GA a release with support for CSE 4.1 and let us know if you run into issues.

My TMC Local is not working as I am waiting for a newer version compatible with CSE 4.1. But I was trying to use Acces Roles to manage/limit K8s API access (e.g: limit certain users to certain namespaces) What I noticed was that you need  either tmc-admin` or `tmc-member` roles to log onto TMC CLI (the command line interface for TMC), which allows you to access the k8s API via kubectl. Having  tmc-admin` or `tmc-member` roles automatically gives full (admin) access to TMC managed K8s clusters and I am therefore unable to limit certain users or groups (i.e.: useer `johndoe` should only be able to list namesapces fro k8s cluster xyz). I hope this makes sense. If not, lets wait for a new version of TMC that supports CSE 4.1. Will reinstall and can get into a meeting.

We are still looking into this but I want to make sure I understand what you would like to achieve. Are you trying to use the "Cloud Administrator" role to grant access to the TMC-SM API/GUI so they can define policies/packages/etc in TMC-SM?

@nhutphan1987 Sorry for the inconvenience! Can you please show us the full error message - click on the failed "Create" action in the UI and give us the text of the error message? This will help us troubleshoot and understand why this happened in your case.

Is there a newer version of TMC local that is compatible with CSE 4.1? I tried to install it but it is complaining that no CSE server is available ``` root@PhotonOS-001 [ ~ ]# /mnt/cdrom/linux.run create instance --name $TMC_SM_INSTANCE_NAME --host $VCD_HOSTNAME --username $VCD_USERNAME --certificate-file /tmp/vcd.pem --encryption-key ${TMC_SM_ENCRYPTION_KEY} --input-kube-cluster-name=${TMC_SM_KUBE_CLUSTER_NAME} --input-cert-provider=cluster-issuer --input-cert-cluster-issuer-name=selfsigned-ca-clusterissuer --input-dns-zone=${TMC_SM_DNS_ZONE} --input-contour-envoy-load-balancer-ip=${TMC_SM_LOAD_BALANCER_IP} --input-harbor-url=${TMC_SM_HARBOR_URL} --input-harbor-username=${TMC_SM_HARBOR_USERNAME} --accept INFO [0019] Creating Solution instance entity instance=vmware.vcd-tmc-0.1.0-21897297-tmc INFO [0019] Triggering action action=hook event=PreCreate INFO [0020] Run EventPreCreate Hook action=hook event=PreCreate INFO [0020] Run EventPreCreate Hook successfully action=hook event=PreCreate INFO [0021] Creating element name=rde INFO [0021] Creating element name=tmc-admin-global-role INFO [0022] Creating element name=tmc-member-global-role INFO [0023] Creating element name=rights-bundle INFO [0023] Triggering action action=hook event=PostCreate INFO [0024] Run EventPostCreate Hook action=hook event=PostCreate INFO [0024] Copy the rights from global roles [Kubernetes Cluster Author] to the global role [tmc:member] action=hook event=PostCreate INFO [0025] Update rights of global role tmc:member action=hook event=PostCreate INFO [0025] Copy the rights from global roles [Organization Administrator Kubernetes Cluster Author] to the global role [tmc:admin] action=hook event=PostCreate INFO [0025] Update rights of global role tmc:admin action=hook event=PostCreate INFO [0025] Get Solution Org action=hook event=PostCreate INFO [0025] Solution Org: CSE action=hook event=PostCreate INFO [0025] Search CSE4 Cluster action=hook event=PostCreate ERROR [0025] Failed to find any cse cluster in org CSE action=hook event=PostCreate ERROR [0026] Failed to create instance 'tmc' name=tmc ERROR [0026] Failed to find any cse cluster in org CSE: exit status 6: failed to execute trigger hook errorCode=5012110011142353 ```

Thanks, Radostin! Some further replies: For VM disks, I am thinking for example of cloning the VM and decrypting the clone in vCenter console. Alternately we could use a backup provider with crypto admin access to backup decrypted disks and restore them elsewhere. Your understanding of our setup is correct. Keep in mind that I was using vSphere encryption as my mental model, so that each VM would have its own key issued by the KMS, which ideally would be visible to the tenant in the Director portal as an attribute of the VM, and which would also allow for the rekeying of VMs on an individual basis. It seems to me your setup is more similar to vTA in that a single key issued by the KMS will be used to protect the keys in use for all VMs. So I agree with you that with this approach there is not as much apparent value to the tenant as there would have been in the key-per-VM scenario that I envisioned. It seems like there is some dissonance between what your model wants to achieve and what we want to achieve for our customers. I'm happy to get on a call. I work regularly with Jon Schulz as well. I have availability this week but am traveling the following two weeks, then will be back in the office the week of the 18th. Thanks!