This is a continuation of a previous articles on IaC shortcomings and resolutions. The case study in this example refers to the use of alias which are different from keys and names used in the resource definition using the IaC modules. Aliases are friendly names in place of the actual names used for the resources which are usually multi-part and have a predefined format with prefixes and/or suffixes. 

While the names must be unique, conform to patterns and conventions, appear within a certain limit for maximum characters and must belong to a namespace or scope,  aliases are less restrictive and usually short form for the names. These aliases are very helpful to use repeatedly in definitions, scripts and languages and serve the purpose in runtime, operating systems and cloud resources.

An alias is only valid in the plane that is defined in and not in the layers above or below. For example, an alias used in the SQL statements for the purposes of referring to existing database objects is only valid in the database and is saved in the master catalog. It does not hold any meaning in the cloud resources. Specifically, cloud resources might also make use of their own aliases and it is convenient to have the same value within different layers but they hold significance only in their specific layer.

Some aliases are used as labels as well but a label is just that and has no backing property, storage or target resources. These labels are also interchangeable without any impact to functionality and might serve additional analytical usages such as for billing. One such example is the Microsoft Entra Admin alias where the actual value used for securing the resource is passed in as an entity id to the aad_object_id attribute and is independent of the alias. The usage of the id and alias in the same resource definition is quite popular because one is used for display purposes and the other is used for the backend processing and referencing purposes.

Associations can also be referred to with alias such as key vault keys but it is important not to over engineer the alias with the same rigor as for names. Whenever we draw a list, whether it is for names or aliases, we tend to codify additional metadata inlined into them by using prefixes and suffixes but it is incorrect in the case of aliases.

When the associations are to logins and identities, they will automatically gain usage in the resources. It is not necessary to add role assignments and all users will use this credential whenever they are anonymously accessing resources across the wire. To pass through their respective credentials, they must ask the resource to do so by virtue of the properties allowed in their definitions or settings.

Reference: previous articles