KThorlund
Enthusiast
Enthusiast

vCACCAFEResourceElement -> Destroy

Jump to solution

Uh, I am busy asking questions these days...

Within vRA there is an action, Destroy, which is available via the Entitlements.

I dont wanna use this action, but create my own, as I need to make some initial check and input prior to destroying the deployment. E.g. I have made a customm Destroy which check is requesting user is == deployment owner...

Thou, I can not find any method on a vCACCAFE / VCAC resource element, which allows me to destroy it.

I can only call the resource action, Destroy, which will work. But the Destroy actions needs to be available in my entitlement before I can use it in my custom action 😕 It would be OK as long I could make the Destroy available as hidden (...) or similar, but I cant...

Any suggestions - how can destroy my element, or hide the default Destroy?

Short written / target: I only want the owner of a deployment to be able destroy the deployment.

Regards, Kjeld

0 Kudos
1 Solution

Accepted Solutions
KThorlund
Enthusiast
Enthusiast

I think I can limit the use of Destroy by using an approval policy:

Auto approve if requester == owner

Sent request to owner if requester != owner

Is OK as a workaround, thou, I would still prefer my initial request.. Smiley Happy

View solution in original post

0 Kudos
4 Replies
KThorlund
Enthusiast
Enthusiast

I think I can limit the use of Destroy by using an approval policy:

Auto approve if requester == owner

Sent request to owner if requester != owner

Is OK as a workaround, thou, I would still prefer my initial request.. Smiley Happy

View solution in original post

0 Kudos
stevedrummond
Hot Shot
Hot Shot

What we do is create two entitlements; one for users and one for administrators (including our service account).

We remove the Destroy action from the User entitlement and replace it with Custom Destroy. The vRO workflow initiated by the custom destroy will call the native Destroy using the service account (which is configured to run the vCACCAFE:Host connection) as it is still entitled to the native action.

Our use case wasn't the same as yours though. We actually needed to remove Destroy from machine components to stop people breaking multi-machine deployments. We swapped out Destroy for Cloud.Machine and Virtual.Machine with a custom action called Destroy Deployment that was just a wrapper for figuring out the root deployment resource and calling the native destroy for it. Users themselves were still entitled to Destroy at the deployment level.

As I mentioned in the other thread, you've really only got those three options.

0 Kudos
KThorlund
Enthusiast
Enthusiast

Hmm, interresting. A service account sounds like the right direction for me.. Thou, I guess I miss some very basic knowledge about the vRA/vRo - I am not sure if the lack relates to access and entitlements or my vRO code... Most likely both Smiley Happy

I already have a service account, which has been assigned all roles in Custom Groups in vRA. (The tab Entitled Items is still empty, and I am not sure from where this is populated / assigned...).

The service account is listed as Group Manager under the BG configuration.

In my new vRO code, I connect to the host with getHostWithCredentials

var vCACCAFEHost = vCACCAFEEntitiesFinder.getHost("ggfd890g-754c-4884-9420-gfd7g987gfd");

vCACCAFEHost = vCACCAFEHost.getHostWithCredentials(vCACCAFEHostUser,vCACCAFEHostPassword);

System.log("vCACCAFEHost: " + vCACCAFEHost);

System.log("");

My output confirms that I am connected with the service account...

If I list the actions on my deployment, I only see what I have assigned via Catalog Management in vRA. Fair.

No Destroy, as it is not assigned to the BG entitlements

And here it breaks for me..

How does my service account get access to the Destroy action, when not available in the BG Entitlement, thou the same user has all possible rules assigned in Group Management?

What am I missing - - other then the basics.. Smiley Happy

I guess my service account somehow and somewhere needs to have some entitlements assigned which are not with the BG entitlements..?

0 Kudos
stevedrummond
Hot Shot
Hot Shot

You're confusing roles and access with entitlements; you also seem to be under the impression you can only have one entitlement per business group.

Access to Catalog items and Day-2 actions comes from Entitlements which are business group specific. You cannot add someone to an entitlement unless they are part of a business group (user, support user, etc.). You can create as many entitlements for a business group as you like.

So what you would do is create two entitlements. Consumer-MyBGName and Admin-MyBGName (example names only of course). Grant admin everything including Destroy; grant consumer whatever you like and obviously do not give them destroy. Add your service account to the admin group.

However thinking over your exact use case last night, I think your better option is to go with the approval policy. This way you don't need to mess around with accounts, entitlements or submitting requests through vRO. Let people submit the destroy and the approval policy will natively reject if they are not the owner. One thing you would need to validate is whether that prevents Lease Expired/Archive destroys from going through (which run as cafe-<id> accounts) if you use leasing.

If you have many entitlements you will want to automate assigning the approval policy to the relevant Destroy actions (there are many) in the entitlements.

0 Kudos