This is a continuation of articles on Infrastructure-as-code aka IaC for short.  There’s no denying that IaC can help to create and manage infrastructure and that they can be versioned, reused, and shared – all of which helps to provision resources quickly and consistently and manage them consistently throughout their lifecycle. Unlike software product code that must be general purpose and provide a strong foundation for system architecture and aspiring to be a platform for many use cases, IaC often varies a lot and must be manifested in different combinations depending on environment, purpose and scale and encompass complete development process. It can even include CI/CD platform, DevOps, and testing tools. The DevOps based approach is critical to rapid software development cycles. This makes IaC spread over in a variety of forms. The more articulated the IaC the more predictable and cleaner the deployments.  

One of the challenges of working with IaC that is somewhat unique to IaC is that authors frequently encounter errors in the ‘apply’ stage of the IaC and do not detect any errors in the ‘plan’ stage of the IaC. This leads to write-once-and-fix-many-times and appears to be unavoidable. The compiler only catches limited set of errors such as when a key is specified instead of an id but whether its only at runtime can an id be tried and found to be correct or not. A guid for a principal id is common for role assignments but whether the guid is appropriate for a particular role assignment depends on the principal to which the guid belongs as well as the intended target. One way to overcome this limitation is to have a pre-production environment where the code can be applied in a similar way. By the nature of the non-production environment maintaining a separate set of resources than the production environment, sometimes, even this is difficult to do. In such cases, some experimentation might be involved where the IaC is applied once to add and again to remove leaving behind a clean slate. Both non-production and production environments are secured with DevOps pipelines so that IaC is pushed to these environments which results in raising a request and following through each time. Fortunately, there is a better way to scope down problematic or suspicious IaC code snippets and try it out in a personal azure subscription. This approach strongly eliminates all doubts and works without the touch points required for pipelines. And since the sandbox is of no concern to the business, it is even facilitated by organizations to work for all employees and by public cloud as free accounts.

Another challenge that routinely requires more experimentation is for applying permissions to managed identities. Every resource can have its own system managed identity but deployments comprising of resources and their dependencies can have a common user managed identity to govern them. In this case, the identity must be granted permission on all those resources. Several built-in roles varying per resource are applicable to the environment, but the principle of least privileges can only be honored by increasing privileges step-by-step. This calls for a gradation in built-in roles to be tried out for successful application deployments.

Similarly, access is also about connectivity, and it might be surprising that 404 https status code can also imply network failure when the error is being translated from an upstream resource. Some resources have mutual exclusivity between public access and private access. Granting public access with restrictions to some ip addresses might be a hybrid approach that works sufficiently enough to secure resources. It is also important to note that Azure services can bypass general deny rules.

These are some resolutions that can be categorized as miscellaneous under the IaC.