vRealize Automation

1. Integration with Public Clouds

2. Tags and Policies

Module 7 :- Integration with Public Clouds

vRealize Automation supports native integration with public cloud platforms, including Amazon Web Services, Microsoft Azure,
Google Cloud Platform, VMware Cloud Foundation, and VMware Cloud on AWS. Creating cloud accounts in vRealize Automation
allows you to integrate with public cloud platforms and deploy services. .

Learner Objectives

• List the public cloud accounts supported by vRealize Automation

• Create an Amazon Web Services public cloud account
• Create a Microsoft Azure public cloud account
• Create a Google Cloud Platform public cloud account
• Create a VMware Cloud Foundation public cloud account
• Create a VMware Cloud on AWS public cloud account
Public Cloud Support

vRealize Automation includes native support for adding public cloud accounts:

• Amazon Web Services

• Microsoft Azure
• Google Cloud Platform
• VMware Cloud Foundation
• VMware Cloud on AWS
Amazon Web Services: Credentials
An Amazon Web Services cloud account requires:
• Access key ID
• Secret access key

To create an access key:

1. Log in to the Amazon Web Services console by using a power
user account with read and write privileges.
2. Navigate to Identity and Access Management (IAM) > Users >
Security Credentials.
3. Click Create access key.

Access keys consist of the following parts

• Access key ID of 20 digits, for example,
AKIAIOSFODNN7EXAMPLE
• Secret access key, for example,
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Amazon Web Services: Cloud Account

To create a cloud account:

1. Log in to the vRealize Automation console as Cloud

Assembly Administrator.
2. Select the Amazon Web Services cloud account type.
— Access key ID
— Secret access key
— Name
3. Click VALIDATE and select the Amazon Web Services
regions to deploy services.
4. Click ADD
Amazon Web Services: Simple Cloud Template

Drag components from the AWS section to the design canvas to create a cloud template. Deployed resources are
hosted on Amazon Web Services

In the example, an Amazon instance and cloud network are dragged to the design canvas
 Microsoft Azure: Credentials
Log in to the Microsoft Azure console as an organization owner to
gather information:
• Subscription ID
• Tenant ID
• Client application ID
• Client application secret key

Subscription ID: Allows you to access to your Microsoft Azure

subscriptions.

Tenant ID: The authorization endpoint for the Active Directory

applications that you create in your Microsoft Azure account.

Client application ID: Provides access to Microsoft Active Directory in

your Microsoft Azure individual account.

Client application secret key: The unique secret key generated to pair
with your client application ID. The secret key can be generated by
clicking the VMware-HCS-Principal application in this example.
Create an Active Directory application as described in the Microsoft
Azure website at https://azure.microsoft.com/en-
us/documentation/articles/ resource-group-create-service-principal-
portal.
Microsoft Azure: Cloud Account

To create a cloud account:

1. Log in to the vRealize
Automation console as Cloud
Assembly Administrator.
2. Select the Microsoft Azure
cloud account type.
— Subscription ID
— Tenant ID
— Client application ID
— Client application secret key
— Name
 Microsoft Azure: Simple Cloud Template

Drag components from the Microsoft Azure section to the design canvas to create a cloud template. Deployed
resources are hosted on Microsoft Azure.

In the example, an Amazon instance and cloud network are dragged to the design canvas.
 Google Cloud Platform: Credentials
A Google Cloud Platform account requires:
• Project ID
• Private key ID
• Private key
• Client email

To generate the private key ID and private key:

1. Log in to the Google Cloud Platform console as organization
owner.
2. Navigate to IAM & admin > Service accounts and Edit the service
account.
3. Click +CREATE KEY to generate the private key ID and private key.

The project ID is available on the Google Cloud Platform console

dashboard
 Google Cloud Platform: Cloud Account
To create a cloud account:
1. Log in to the vRealize Automation console as Cloud Assembly
Administrator.
2. Select the Google Cloud Platform cloud account type.
— Project ID
— Private key ID
— Private key
— Client email
3. Click VALIDATE and select the Google Cloud Platform regions
to deploy services.

Alternatively, you can click IMPORT JSON KEY to autofill the

required fields.

Clicking CREATE KEY, downloads a JSON file that includes all the
required attributes, including the project ID, private key ID,
private key, and client email. Store the file securely because this
key cannot be recovered if lost. You can generate a new file.
Google Cloud Platform: Simple Cloud Template

Drag components from the GCP section to the design canvas to use these objects in vRealize Automation.
About VMware Cloud Foundation
VMware Cloud Foundation delivers a natively
integrated software-defined data center stack that
includes core infrastructure virtualization, vSphere,
vSAN, and NSX-T Data Center.
SDDC Manager automates the entire system life cycle
(from configuration and provisioning to upgrades and
patching), and simplifies day-to-day management and
operations.

VMware Cloud Foundation supports automated

deployment of vRealize Suite Lifecycle Manager. You
can then deploy and manage the life cycle of the
vRealize Suite of products (vRealize Log Insight,
vRealize Automation , and vRealize Operations
Manager) through vRealize Suite Lifecycle Manager.
VMware Cloud Foundation 4.0.x provides a
standardized and configured infrastructure for vSphere
with Tanzu.
SDDC Manager Integration

Before creating a VMware Cloud Foundation

cloud account, you must integrate with SDDC
Manager:
1. Navigate to Infrastructure > Connections >
Integrations.
2. Click +ADD INTEGRATION.
3. Select SDDC Manager.

Edit the SDDC Manager integration:

1. Select the workload domain.
2. Click ADD CLOUD ACCOUNT.
VMware Cloud Foundation: Cloud Account
The selected workload domain is used to create the
VMware Cloud Foundation cloud account:
• One cloud account per workload domain.
• Create service credentials or use the existing
credentials.
• Configure cloud zone and image or flavor mappings.
• Resources are deployed on the workload domain.

Auto Configuration: Service credentials are

automatically created on the vCenter Server system.
These service credentials are used to validate the
cloud account. Certificates are automatically accepted.
VMware Cloud on AWS

VMware Cloud on AWS brings the VMware enterprise-class SDDC software to the Amazon Web Services (AWS) cloud with
optimized access to AWS services. VMware Cloud on AWS is an integrated cloud offering jointly developed by Amazon Web
Services (AWS) and VMware. You can deliver a highly scalable and secure service by migrating and extending your on-premises
environments based on vSphere to the AWS Cloud running on Amazon Elastic Compute Cloud (Amazon EC2).
VMware Cloud on AWS: Credentials

The VMware Cloud on AWS cloud account requires an API token.

To generate an API token:

1. On the VMware Cloud Services toolbar, click your username and

select My Account > API Tokens.

a.. Enter the token name.

b.. Specify the lifespan of the token.
c.. Define scopes for the token.
2. Click GENERATE.

You use API tokens to authenticate yourself when you make

authorized API connections.
For security reasons, only the token name is displayed after you
generate the token. The token credentials are not displayed. You can
reuse the token by copying the credentials from this page. You can
regenerate a token at any time.
VMware Cloud on AWS: Cloud Account
To create a cloud account:

1. Log in to the vRealize Automation console as Cloud

Assembly Administrator.
2. Select the VMware Cloud on AWS cloud account
type.
— VMC API token
3. Click APPLY API TOKEN.
4. Select the appropriate SDDC from the drop-down
menu.
5. Enter the vCenter Server credentials for the
selected SDDC.
6. Click VALIDATE.
 (Simulation) Configuring the VMware Cloud Foundation Account

Create a VMware Cloud Foundation cloud account and deploy a simple cloud template:
1. Create an SDDC Integration
2. Create a VMware Cloud Foundation Cloud Account
3. Create a Project and Add a Cloud Zone
4. Create a Flavor Mapping
5. Create an Image Mapping
6. Create a Simple Cloud Template
7. Deploy and Validate the Resource
From your local desktop, go to https://vmware.bravais.com/s/VxigGjP0tz98Jqxit5J8 to open the
simulation
(Simulation) Configuring the Public Cloud Accounts

Create a public cloud account and deploy a simple cloud template:

1. Create a Public Cloud Account
2. Create a Project and Add a Cloud Zone
3. Create a Flavor Mapping
4. Create an Image Mapping
5. Create a Simple Cloud Template
6. Deploy and Validate the Resource
Use one of these public cloud accounts:
• Amazon Web Services: https://vmware.bravais.com/s/RNbJc4St7K8LSWlY2kUQ
• Microsoft Azure: https://vmware.bravais.com/s/ZvPudZK5y74kRP0dbeC2
• Google Cloud Platform: https://vmware.bravais.com/s/IRjFRs5Lg7sbmBqnoaYK
IMPORTANT
These are simulations. Do not perform these steps in your actual lab environment
Module 8 :- Tags and Policies in vRealize Automation

1. Overview of Tagging

2. Policy Definitions
Tags in vRealize Automation

Tags are available in vRealize Automation:

• Tags are labels that you apply to resources.

• Tags can be of the form key or key:value.
• Different types of tags are available:
— Capability tags
— Constraint tags
— Resource tags
 Capability Tags

Capability tags enable you to categorize

resources based on the capabilities that
they provide.
You can apply capability tags to the
following types of resources:
• Cloud accounts
• Integrations
• Cloud zones
• Virtual private zones
• Kubernetes zones
• Network profiles
• Storage profiles
Constraint Tags

Constraint tags enable you to

govern how vRealize
Automation selects resources to
use during deployments.

You can apply constraint tags to

the following types of
resources:

• Cloud templates
• Image mappings
• Projects
 Tags in Projects

You can specify network constraints, storage

constraints, and extensibility constraints on
a project.
Project constraint tags take precedence over
cloud template constraint tags.
Additionally, you can set resource tags on a
project.

If the same constraint is specified in both

the project and the cloud template, then the
constraint specified in the project takes
precedence
Tagging Strategies

Follow these suggestions when developing

your tagging strategy:
• Tag enough to be useful. Do not tag
excessively.
• Use key:value style tags rather than key
style tags.
Lesson 2 :- Policy Definitions

Policies are a set of rules or parameters that

are applied to enable governance and process
your deployments.

Click the Content & Policies tab and navigate

to Policies > Definitions.

Currently, the following policy types are

available:

• Approval Policy

• Day 2 Actions Policy

• Lease Policy

A policy that you create is applied to new

deployments and to current deployments. If
you create a policy,
Policy Type: Approval Policy
You configure an approval policy to have governance and
control over deployment requests and day-2 action
requests.

Use cases:

• Approve a deployment that consumes a large amount of

resource

• Approve the day-2 action of a deployment that many

users consume

The Service Broker administrator is responsible for

configuring an approval policy. Policies are applied to
resources that are consumed by catalog users.

Scope: The scope determines if the policy is applicable to all

deployments in this organization or to only deployments in
a selected project.

Deployment Criteria: If you want to further refine when the

policy is applied within the selected scope, you add a policy
criteria
Policy Type: Approval Policy

Approver Mode:
• Any: Only one approver must approve the request before it is processed.
• All: All approvers must respond with the same response before the request is processed. If one approver rejects the
request, the request is denied, and the user is notified.

Approvers: Add the name or email address for each approver. The approval request is sent to all approvers at the same
time.
An approver, who might not be a regular Service Broker or Cloud Assembly user, must have one of the following
combination of roles:
• Organization member and Service Broker user
• Organization member and the Manage Approvals custom role
These roles provide the minimum level of permissions and still allow them to approve or reject a request.
Policy Type: Approval Policy

Auto expiry decision: Automatically approve or reject a request after the number of days specified in the
Auto expiry trigger field.

• Approve: The request is approved if an approver does not respond in the amount of time specified.

• Reject: The request is denied if an approver does not respond in the amount of time specified.

Auto expiry trigger: The number of days the approvers have to respond before the Auto expiry decision is
triggered. The value should be in the range of 1 through 7 days.

Actions: Select one or more actions that the policy applies to. The actions include deployments and
component level day-2 actions.
Approval Requests
When a deployment or day-2 action request from a catalog user matches the approval policy criteria, the request is sent to
approvers.
The catalog user must wait for the approvers to approve their requests. Users can monitor the approval request from their
Approval tab.

All approvers receive an email notification with the approval details. The approver must log in to Service Broker and use the
Approvals tab to accept or reject a request.

The catalog user receives an email notification when the approver responds to a request.
 Policy Type: Lease Policy
The lease policy enables administrators to control the
number of time deployments are available to the users.
If you do not have any lease policies defined, then the
deployments never expire.
When a lease policy is created or updated, it
continuously evaluates the deployments in the
background to ensure that they comply with the
defined leases.
Enforcement type: Enforcement is either hard or soft.
Hard policies are ranked higher than soft policies. Hard
policies override soft policies. If a conflict occurs
between a soft lease policy applied to an organization
and a hard lease policy applied to a project, the project
lease policy takes precedence because it is more
specific.
Policy Type: Lease Policy

Maximum lease (days): The maximum number of days that a deployment can be active initially at the
deployment time or when users extend a lease, for example, 30 Days.
Maximum total lease (days): In this scenario, the deployment is shut down after 30 days and an email is sent
to the user. If the user does not extend the lease, the deployment is destroyed after 10 days. If the user
extends the lease for 30 more days, and another 30 days, for a combined total of 90 days, the maximum
lease time is reached, and the deployment is shut down. The deployment is destroyed 10 days later, for
example, 90 Days.
Grace period (days): The number of days after a lease expires before it is destroyed. This grace period allows
users to extend the lease for another block of time that does not exceed the Total Lease value, for example,
10 Days.
Policy Type: Day 2 Actions Policy

Day 2 Action policies enable the

administrator to control changes
that users can make to
deployments and their
component resources.

If you do not have any Day 2

Action policies defined, then no
governance is applied, and all
users have access to all the
actions.
Policy Type: Day 2 Actions Policy

Role: You can entitle users to run actions based on roles. To grant certain action privileges to a role,
you can create a policy for that role.
• Administrator: Entitle the project administrators associated with the deployment to run the
selected actions. Administrators can also run any actions that their project members can run.
• Member: Entitle the project members associated with the deployment to run the selected actions.
• Custom Role: If you have one or more custom roles defined, you can select a named role in the list.
The users assigned to the role are entitled to run the selected actions on the deployments in their
projects.

Actions: Actions are cloud-specific. When you are entitling the users to make changes, consider what
cloud accounts the entitled users are deploying to and ensure that you select all the cloud-specific
versions of the actions. For example, if you want to allow changes to an AWS instance, then add
Cloud.AWS.EC2.Instance.Resize action to entitle users to resize AWS instances
Monitoring Deployments
Requests can be monitored on the Deployments tab. Click the requested item to view the deployment details.
Topology: To visualize the deployment structure and resources.
History: Provisioning events and any events related to actions that you run after the requested item is deployed. If the provisioning
process fails, the History tab events help you with troubleshooting failures.
Additionally, the Pricing, Monitor, and Optimize tabs are available when integrated with vRealize Operations Manager.
Managing Deployments

A Service Broker user can manage the whole

deployment with limited options.
Click the deployment and select the object
(VM in this example). Click ACTIONS to
manage the object.

The options available for a Service Broker user

to manage the deployment and its objects
depends on the policies defined by the Service
Broker administrator.
Questions.. ??