How to hide sources codes from end users in a Managed Application

KT 170 Reputation points
2023-09-04T02:51:07.14+00:00

Hi,

In a Managed Application, we would like to prohibit end users from accessing our sources code in Azure Functions.

Is it possible to prevent users from accessing only Azure Functions in the managed resources? If not, we only have an option with obfuscated code?

Azure Managed Applications
Azure Managed Applications
An Azure service that enables managed service providers, independent software vendors, and enterprise IT teams to deliver turnkey solutions through the Azure Marketplace or service catalog.
138 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. RevelinoB 2,780 Reputation points
    2023-09-04T04:26:43.97+00:00

    Hi KT,

    To answer your question, if you're deploying an Azure Function as part of a managed application, you'll likely want to ensure that end users (those who deploy the managed application) can't access the source code of the Azure Function.

    Here are some options to consider:

    • Azure Functions Premium Plan with Private Endpoints: The premium plan for Azure Functions offers the ability to use VNET integration and private endpoints. This allows you to make sure that the Azure Function is only accessible from certain VNETs, which can provide a level of isolation.
    • Use Compiled Code: Instead of deploying script files (.csx, .js, .py, etc.), use precompiled binaries. For instance, if you're using C#, you can compile your function app to a DLL, which makes it more difficult (though not impossible) for someone to retrieve and understand the source code.
    • Obfuscation: As you mentioned, you can obfuscate your code. This doesn't prevent access to the code, but it does make it much harder to understand. Tools like ConfuserEx can be used for .NET applications, and there are similar tools for other languages.
    • Azure Managed Applications RBAC: If you're packaging your resources as an Azure Managed Application, you can use Azure's Role-Based Access Control (RBAC) to limit permissions. Azure Managed Applications give the managed resource group a 'User Access Administrator' role to the managed application's service principal. This allows the application to manage resources, but it also implies that if the service principal's credentials are compromised or misconfigured, it could allow broader access.
    • Azure Policy: Deploy Azure Policy definitions and assignments as part of your managed application to enforce specific requirements or restrictions. While this won't hide the code, it can prevent certain unwanted configurations or deployments.
    • Azure Function Proxies: Instead of exposing your function directly, you can use Azure Function Proxies to create a facade. This doesn't hide the code, but it can mask the actual function endpoint. It's important to understand that no method will be 100% foolproof. A determined attacker with the right permissions can likely retrieve the source code or binary, but these methods can make it significantly more challenging.

    It's also always a good practice to follow the principle of least privilege: grant only the permissions necessary for a user or service to perform its job and nothing more. This can help in limiting potential exposure points.

    I hope this helps?


  2. Ryan Hill 28,106 Reputation points Microsoft Employee
    2023-09-29T16:32:59.5133333+00:00

    Apologies for the delayed response here @KT . With regards to your question, no, source code is not viewable from a published managed application. Protection of IP is one of the main reasons to leverage managed app.

    When you published the managed app, it's a packaged along with its dependencies into a template that's deployed to your customers subscription. As the publisher you can also limit access to certain resources within the managed app.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.