anjuna-azure-cli instance
Create and manage Azure Confidential VMs.
You must be logged in to a valid Azure account permitted to create and manage Azure Confidential VMs. |
DESCRIPTION
The anjuna-azure-cli instance
tool supports the following options to manage
Azure Confidential VMs:
-
create
: Create a new instance -
describe
: Get status information for confidential VMs -
log
: Read the boot log for confidential VMs -
log-enable
: Enable boot diagnostic logging for confidential VMs -
log-disable
: Disable boot diagnostic logging for confidential VMs
Creating an Azure Confidential VM requires an Azure-compatible disk image. See anjuna-azure-cli disk for a description of the tools needed to create and upload disk images.
Use the az account show
command to confirm that you are logged in.
If you are not logged in, consider using the az login
command to initialize your az
session.
anjuna-azure-cli instance create
The anjuna-azure-cli instance create
tool creates AMD SEV instances on Microsoft Azure.
anjuna-azure-cli instance create --name <INSTANCE_NAME> --location <INSTANCE_LOCATION> [OPTIONS]
The instance create
command allows you to optionally specify a storage account to record the boot diagnostics logs.
These logs are used to provide the serial console logs functionality in Azure.
You can also enable the logs after the CVM has been started by using the az vm boot-diagnostics enable
command.
If a network interface, virtual network, subnet, or network security group is not provided to anjuna-azure-cli instance create
,
Azure automatically creates the necessary resources in the resource group associated with the CVM.
Alternately, you can create the associated network resources in advance using the az
commands or by using Terraform and attach them to the CVM with anjuna-azure-cli instance create
.
When the --nics option is used to attach one or more network interfaces,
then the other network related options cannot be used, or Azure will report an error.
The NSG, vnet , and subnet need to be configured in the NIC(s).
|
These following Azure CLI commands may be helpful:
|
OPTIONS
--assign-id strings resource ID of the identity (use [system] for system assigned identity) --image-definition the Azure Image Definition to use --image-gallery the Azure Image Definition's parent shared image gallery --image-version string the image version to use --location string (Optional) the location to associate with your resources --name name of the VM instance to use --resource-group the Azure resource group to be used for the artifacts needed for this operation --role string role (name or resource Id) to be assigned to the system assigned identity --scope string scope, specified as a resource Id, of the role for the system assigned identity --instance-type Type of the VM instance to create (default: Standard_DC2as_v5) --nics <nic> | "nic0< nic1< nic2...>" names (<nic> | "nic0< nic1< nic2...>") of the network interfaces to attach (default: automatically created) --nsg_association name of Network Security Group (default: automatically created). Use "" for none --storage-account storage account for the boot-diagnostic logs --subnet name of the subnet (default: automatically created) --vnet name of the virtual network (default: automatically created)
When the --storage-account flag is specified,
the Anjuna CLI will enable the Azure boot diagnostics mechanism,
which writes VM system boot logs to the given storage account.
The boot diagnostics can also be enabled after an instance is created,
using the anjuna-azure-cli instance log-enable command described below.
|
When an Azure Confidential VM is created, Azure automatically creates a new OS disk from the specified image and attaches it to the instance. During its runtime, the instance uses the disk for persistent storage, changing the disk content.
Restarting the instance through the az CLI or the Azure Portal reuses the disk which results in a different initial state and could compromise the security of the deployment.
Instead of restarting the instance, Anjuna recommends deleting it and creating a new one.
In a future release, the Anjuna Runtime will fail to start the Anjuna Confidential Container for SEV on Azure if the disk is being reused.
|
Azure also automatically creates and associates network resources with a VM if they are not explicitly specified. Resources such as Virtual Networks and Network Security Groups are not automatically deleted, because they can be shared among many Azure Confidential VMs. They will continue to consume resource quotas.
anjuna-azure-cli instance delete
(described below) can be used to automatically delete the VM along with the attached resources including the OS disk, network interfaces, and public IPs.
Assign Managed Identities to Azure Confidential VMs
The anjuna-azure-cli allows an identity to be assigned to the Anjuna Confidential Container when it is created.
--assign-id
can be used to configure identities on the Anjuna Confidential Container at the time of instantiation.
Multiple identities can be added, including the "system-assigned" identity ('[system]') and managed identities.
This gives the Anjuna Confidential Container the rights to access any resource or service included in the 'scope' defined for the identity, and credentials would not need to be embedded in the code or retrieved from the Anjuna Policy Manager.
The --scope
and --role
command line options can be used to customize the access with the system created identity.
Additional References:
The assigned identity can be queried as shown below. In this example, a system created identity was assigned to the Anjuna Confidential Container
$ az vm show --name <vm-name> --resource-group <resource-group-name> --query .identity
It will return something similar to:
{
"principalId": "0sdfeef-8ad6-4344-808c-b0b0b0b0b07e",
"tenantId": "29098345-4cc9-4a53-a086-bfefefe89789",
"type": "SystemAssigned",
"userAssignedIdentities": null
}
Microsoft Azure documentation defines the two types of identities as follows:
There are two types of managed identities:
System-assigned. Some Azure resources, such as virtual machines, allow you to enable a managed identity directly on the resource. When you enable a system-assigned managed identity:
A service principal of a special type is created in Azure AD for the identity. The service principal is tied to the lifecycle of that Azure resource. When the Azure resource is deleted, Azure automatically deletes the service principal for you.
By design, only that Azure resource can use this identity to request tokens from Azure AD.
You authorize the managed identity to have access to one or more services.
The name of the system-assigned service principal is always the same as the name of the Azure resource it is created for. For a deployment slot, the name of its system-assigned identity is `<app-name>/slots/<slot-name>`.
User-assigned. You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more Azure Resources. When you enable a user-assigned managed identity:
A service principal of a special type is created in Azure AD for the identity. The service principal is managed separately from the resources that use it.
User-assigned identities can be used by multiple resources.
You authorize the managed identity to have access to one or more services.
EXAMPLES
The example below creates an Azure Confidential VM called my-cvm-instance
in westus
using the image hello-world-boot-disk
version 1.0.0
.
The CVM is attached to the network interface (NIC) called example-nic
, which has been previously created using the terraform script below.
The NIC is attached to the example-subnet
and has been configured with a public IP address (using example-pip
).
By virtue of being attached to example-subnet
, it also uses example-vnet
and example-nsg
.
$ anjuna-azure-cli instance create \
--name my-cvm-instance \
--location westus \
--image-gallery myimagegallery \
--image-definition hello-world-boot-disk \
--image-version 1.0.0 \
--resource-group myresourcegroup \
--storage-account mystorageaccount \
--nics example-nic
$ cat network.tf
# Terraform script for creating a permissive network configuration
# Network Security Group
resource "azurerm_network_security_group" "nsg" {
name = "example-nsg"
location = example.location
resource_group_name = example.resource_group
security_rule {
name = "SSH"
priority = 1001
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "22"
source_address_prefix = "*"
destination_address_prefix = "*"
}
security_rule {
name = "HTTP"
priority = 1020
direction = "Outbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "80"
source_address_prefix = "*"
destination_address_prefix = "*"
}
security_rule {
name = "HTTPS"
priority = 1021
direction = "Outbound"
access = "Allow"
protocol = "Tcp"
source_port_range = "*"
destination_port_range = "443"
source_address_prefix = "*"
destination_address_prefix = "*"
}
security_rule {
name = "ping"
priority = 1050
direction = "Inbound"
access = "Allow"
protocol = "Icmp"
source_port_range = "*"
destination_port_range = "*"
source_address_prefix = "*"
destination_address_prefix = "*"
}
}
# Virtual Network
resource "azurerm_virtual_network" "vnet" {
name = "example-network"
address_space = ["10.0.0.0/16"]
location = example.location
resource_group_name = example.resource_group
}
# Subnet
resource "azurerm_subnet" "subnet" {
name = "example-subnet"
resource_group_name = example.resource_group
virtual_network_name = azurerm_virtual_network.vnet.name
address_prefixes = ["10.0.1.0/24"]
}
# Associate Network Security Group with Subnet
resource "azurerm_subnet_network_security_group_association" "nsg_association" {
subnet_id = azurerm_subnet.subnet.id
network_security_group_id = azurerm_network_security_group.nsg.id
}
resource "azurerm_public_ip" "public_ip" {
name = "example-pip"
location = example.location
resource_group_name = example.resource_group
allocation_method = "Dynamic"
}
resource "azurerm_network_interface" "nic" {
name = "example-nic"
location = example.location
resource_group_name = example.resource_group
ip_configuration {
name = "internal"
subnet_id = azurerm_subnet.subnet.id
private_ip_address_allocation = "Dynamic"
public_ip_address_id = azurerm_public_ip.public_ip.id
}
}
anjuna-azure-cli instance describe
Use the anjuna-azure-cli instance describe
tool to display information about existing VMs.
anjuna-azure-cli instance describe --resource-group <RESOURCE_GROUP> --name <INSTANCE_NAME> [OPTIONS]
OPTIONS
--json Get instance details formatted as JSON data (verbose) --name string Name of the VM instance to use, required --query string JSON query string. See http://jmespath.org/ for more information and examples. --resource-group Azure resource group to use, required
EXAMPLES
$ anjuna-azure-cli instance describe \
--name my-cvm-instance \
--resource-group myresourcegroup
Name ResourceGroup PowerState PublicIps Fqdns Location Zones
--------------- ------------------ -------------- ----------- ------- ---------- -------
my-cvm-instance myresourcegroup VM deallocated 192.168.1.1 eastus
$ anjuna-azure-cli instance describe \
--json \
--name my-cvm-instance \
--resource-group myresourcegroup
{
"additionalCapabilities": null,
"applicationProfile": null,
"availabilitySet": null,
"billingProfile": null,
"capacityReservation": null,
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": null
}
},
"evictionPolicy": null,
"extendedLocation": null,
"extensionsTimeBudget": null,
"fqdns": "",
"hardwareProfile": {
"vmSize": "Standard_D2s_v3",
"vmSizeProperties": null
},
...
}
anjuna-azure-cli instance log
Use the anjuna-azure-cli instance log
tool to read a VM’s boot log.
anjuna-azure-cli instance log --resource-group <RESOURCE_GROUP> --name <INSTANCE_NAME> [OPTIONS]
OPTIONS
--name string Name of the VM instance to use, required --resource-group Azure resource group to use, required --tail Continuously poll for new boot log messages (press CTRL-C to exit)
EXAMPLES
$ anjuna-azure-cli instance log \
--name my-cvm-instance \
--resource-group myresourcegroup
GRUB_FORCE_PARTUUID set, attempting initrdless boot.
[ 0.000000] Linux version 5.15.0-1039-azure (buildd@lcy02-amd64-067) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #46~20.04.1-Ubuntu SMP Mon May 22 19:42:46 UTC 2023 (Ubuntu 5.15.0-1039.46~20.04.1-azure 5.15.98)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1039-azure root=PARTUUID=009f94b8-8128-45cc-90af-ef644b24e646 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 panic=-1
...
$
$ anjuna-azure-cli instance log \
--tail \
--name my-cvm-instance \
--resource-group myresourcegroup
Tailing boot log, press CTRL-C to exit..
GRUB_FORCE_PARTUUID set, attempting initrdless boot.
[ 0.000000] Linux version 5.15.0-1039-azure (buildd@lcy02-amd64-067) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #46~20.04.1-Ubuntu SMP Mon May 22 19:42:46 UTC 2023 (Ubuntu 5.15.0-1039.46~20.04.1-azure 5.15.98)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1039-azure root=PARTUUID=009f94b8-8128-45cc-90af-ef644b24e646 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 panic=-1
...
anjuna-azure-cli instance log-enable
Use the anjuna-azure-cli instance log-enable
command to enable boot diagnostics for VMs.
By default, the Anjuna CLI enables boot diagnostics for newly-created instances when the --storage-account flag is specified.
|
anjuna-azure-cli instance log-enable --resource-group <RESOURCE_GROUP> --name <INSTANCE_NAME>
anjuna-azure-cli instance log-disable
Use the anjuna-azure-cli instance log-disable
command to disable boot diagnostics for VMs.
anjuna-azure-cli instance log-disable --resource-group <RESOURCE_GROUP> --name <INSTANCE_NAME>
anjuna-azure-cli instance delete
The anjuna-azure-cli instance delete
command can be used to delete an Azure Confidential VM instance. If the --delete-nics
option is used, it will also delete the attached NICs and Public IP addresses.
anjuna-azure-cli instance delete --resource-group <RESOURCE_GROUP> --name <INSTANCE_NAME> [--delete-nics] [--subscription-id <SUBSCRIPTION-ID>]