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.
Tracebit, a system monitoring tool, is built with C# primarily due to its performance characteristics, especially with regards to garbage collection. While other languages like Go and Rust offer memory management advantages, C#'s generational garbage collector and allocation patterns align well with Tracebit's workload, which involves short-lived objects. This allows for efficient memory management without the complexities of manual control. Additionally, the mature .NET ecosystem, cross-platform compatibility offered by .NET, and the team's existing C# expertise contributed to the decision. Ultimately, C# provided a balance of performance, productivity, and platform support suitable for Tracebit's needs.
Hacker News users discussed the surprising choice of C# for Tracebit, a performance-sensitive tracing tool. Several commenters questioned the rationale, citing potential performance drawbacks compared to C/C++. The author defended the choice, highlighting C#'s developer productivity, rich ecosystem (especially concerning UI development), and the performance benefits of using native libraries for the performance-critical parts. Some users agreed, pointing out the maturity of the .NET ecosystem and the relative ease of finding C# developers. Others remained skeptical, emphasizing the overhead of the .NET runtime and garbage collection. The discussion also touched upon cross-platform compatibility, with commenters acknowledging .NET's improvements in this area but still noting some limitations, particularly regarding native dependencies. A few users shared their positive experiences with C# in performance-sensitive contexts, further fueling the debate.
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.