packer-cn/website/content/docs/builders/azure/index.mdx

118 lines
5.9 KiB
Plaintext

---
description: >
Packer is able to create Azure VM images. To achieve this, Packer comes with
multiple builders depending on the strategy you want to use to build the
images.
page_title: Azure images - Builders
---
# Azure Virtual Machine Image Builders
Packer can create Azure virtual machine images through variety of ways
depending on the strategy that you want to use for building the images.
Packer supports the following builders for Azure images at the moment:
- [azure-arm](/docs/builders/azure-arm) - Uses Azure Resource
Manager (ARM) to launch a virtual machine (VM) from which a new image is
captured after provisioning. If in doubt, use this builder; it is the
easiest builder to get started with.
- [azure-chroot](/docs/builders/azure-chroot) - Uses ARM to create
a managed disk that is attached to an existing Azure VM that Packer is
running on. Provisioning leverages [Chroot](https://en.wikipedia.org/wiki/Chroot)
environment. After provisioning, the disk is detached an image is created
from this disk. This is an **advanced builder and should not be used by
newcomers**. However, it is also the fastest way to build a VM image in
Azure.
-> **Don't know which builder to use?** If in doubt, use the [azure-arm
builder](/docs/builders/azure-arm). It is much easier to use.
# Authentication for Azure
The Packer Azure builders provide a couple of ways to authenticate to Azure. The
following methods are available and are explained below:
- Azure Active Directory interactive login. Interactive login is available
for the Public and US Gov clouds only.
- Azure Managed Identity
- Azure Active Directory Service Principal
- Azure CLI
-> **Don't know which authentication method to use?** Go with interactive
login to try out the builders. If you need Packer to run automatically,
switch to using a Service Principal or Managed Identity.
No matter which method you choose, the identity you use will need the
appropriate permissions on Azure resources for Packer to operate. The minimal
set of permissions is highly dependent on the builder and its configuration.
An easy way to get started is to assign the identity the `Contributor` role at
the subscription level.
## Azure Active Directory interactive login
If your organization allows it, you can use a command line interactive login
method based on oAuth 'device code flow'. Packer will select this method when
you only specify a `subscription_id` in your builder configuration. When you
run Packer, it will ask you to visit a web site and input a code. This web site
will then authenticate you, satisfying any two-factor authentication policies
that your organization might have. The tokens are cached under the `.azure/packer`
directory in your home directory and will be reused if they are still valid
on subsequent runs.
Please note that the interactive login is only available on the Azure public
cloud, not on sovereign/government clouds.
## Azure Managed Identity
Azure provides the option to assign an identity to a virtual machine ([Azure
documentation](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/qs-configure-portal-windows-vm)). Packer can
use a system assigned identity for a VM where Packer is running to orchestrate
Azure API's. This is the default behavior and requires no configuration
properties to be set. It does, however, require that you run Packer on an
Azure VM.
To enable this method, [let Azure assign a system-assigned identity to your VM](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/qs-configure-portal-windows-vm).
Then, [grant your VM access to the appropriate resources](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/howto-assign-access-portal).
To get started, try assigning the `Contributor` role at the subscription level to
your VM. Then, when you discover your exact scenario, scope the permissions
appropriately or isolate Packer builds in a separate subscription.
## Azure Active Directory Service Principal
Azure Active Directory models service accounts as 'Service Principal' (SP)
objects. An SP represents an application accessing your Azure resources. It
is identified by a client ID (aka application ID) and can use a password or a
certificate to authenticate. To use a Service Principal, specify the
`subscription_id` and `client_id`, as well as either `client_secret`,
`client_cert_path` or `client_jwt`. Each of these last three represent a different
way to authenticate the SP to AAD:
- `client_secret` - allows the user to provide a password/secret registered
for the AAD SP.
- `client_cert_path` - allows usage of a certificate to be used to
authenticate as the specified AAD SP.
- `client_cert_token_timeout` - How long to set the expire time on the token created when using
`client_cert_path`.
- `client_jwt` - For advanced scenario's where the used cannot provide Packer
the full certificate, they can provide a JWT bearer token for client auth
(RFC 7523, Sec. 2.2). These bearer tokens are created and signed using a
certificate registered in AAD and have a user-chosen expiry time, limiting
the validity of the token. This is also the underlying mechanism used to
authenticate when using `client_cert_path`.
To create a service principal, you can follow [the Azure documentation on this
subject](https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?view=azure-cli-latest).
## Azure CLI
This method will skip all other options provided and only use the credentials that the az cli is authenticated with.
Works with both normal user (`az login`) as well as service principal (`az login --service-principal --username APP_ID --password PASSWORD --tenant TENANT_ID`).
To enable az cli authentication, use the following:
- `"use_azure_cli_auth": true`
This mode will use the `tenant_id` and `subscription_id` from the current active az session which can be found by running: `az account show`