This blog post details a method for securely deploying applications to on-premises IIS servers from Azure Pipelines without exposing credentials. The author leverages a self-hosted agent running on the target server, combined with a pre-configured deployment group. Instead of storing sensitive information directly in the pipeline, the approach uses Azure Key Vault to securely store the application pool password. The pipeline then retrieves this password during the deployment process and utilizes it with the powershell task in Azure Pipelines to update the application pool, ensuring credentials are not exposed in plain text within the pipeline or agent's environment. This setup enables automated deployments while mitigating the security risks associated with managing credentials for on-premises deployments.
The 2008 blog post argues that Windows wasn't truly "free" for businesses, despite the common perception. While the OS itself came bundled with PCs, the associated costs of management, maintenance, software licensing (especially for Microsoft Office and server products), antivirus, and dealing with malware significantly outweighed the initial cost of the OS. The author contends that these hidden expenses made Windows a more expensive option compared to perceived free alternatives like Linux, particularly for smaller businesses. Ultimately, the "free" Windows license subsidized other revenue streams for Microsoft, making it a profitable, albeit deceptive, business model.
Hacker News users discussed the complexities of Microsoft's "free" Windows licensing model for businesses. Several pointed out that while the OS itself might not have a direct upfront cost, it's bundled with hardware purchases, making it an indirect expense. Others highlighted the ongoing costs associated with Windows, such as Software Assurance for updates and support, along with the costs of managing Active Directory and other related infrastructure. The general consensus was that "free" is a misleading term, and the true cost of Windows for businesses is substantial when considering the total cost of ownership. Some commenters also discussed the historical context of the article (from 2008) and how Microsoft's licensing and business models have evolved since then.
Summary of Comments ( 32 )
https://news.ycombinator.com/item?id=43256802
The Hacker News comments generally praise the article for its practical approach to a complex problem (deploying to on-premise IIS from Azure DevOps). Several commenters appreciate the focus on simplicity and avoiding over-engineering, highlighting the use of built-in Azure DevOps features and PowerShell over more complex solutions. One commenter suggests using deployment groups instead of self-hosted agents for better security and manageability. Another emphasizes the importance of robust rollback procedures, which the article acknowledges but doesn't delve into deeply. A few commenters discuss alternative approaches, like using containers or configuration management tools, but acknowledge the validity of the author's simpler method for specific scenarios. Overall, the comments agree that the article provides a useful, real-world example of secure-enough deployments.
The Hacker News post titled "(Reasonably) secure Azure Pipelines on-prem deployments" discussing the linked blog post about secure deployments to IIS using Azure DevOps has generated a small but focused discussion thread. Several commenters engage with the specific technical details and offer alternative approaches or raise potential concerns.
One commenter points out a potential vulnerability if the deployment agent's machine account, which has write access to the web application directory, is compromised. They suggest an alternative where the build agent packages the application, and a separate deployment process, running under a more restricted account, handles the extraction and deployment to IIS. This separation of duties limits the potential damage from a compromised build agent.
Another commenter discusses the complexity and challenges associated with using tools like Ansible for deployments, particularly in Windows environments. They acknowledge the benefits of such tools but highlight the effort required to learn and maintain them, contrasting it with the relative simplicity of the approach presented in the blog post. This commenter suggests that while more sophisticated tools exist, the author's method might be a pragmatic solution for those prioritizing simplicity and ease of implementation.
A third commenter questions the security of storing deployment credentials within Azure DevOps, even if encrypted. They propose using a dedicated secrets management solution like Azure Key Vault for storing sensitive information and retrieving it during the deployment process. This approach enhances security by decoupling the secrets from the deployment pipeline itself.
The overall sentiment in the comments is one of cautious appreciation for the author's approach. Commenters acknowledge the practicality of the solution while also highlighting potential security concerns and suggesting alternative, more secure, albeit potentially more complex, methods. The discussion revolves around the trade-off between simplicity and security in real-world deployment scenarios. No one outright criticizes the author's method but instead offer constructive feedback and alternative perspectives for achieving secure deployments.