Security considerations when using GitHub with Microsoft Fabric Git integration

Reading Time: 5 minutes

In this post I want to share my initial thoughts about security considerations when using GitHub with Microsoft Fabric Git integration.

Since GitHub support for Microsoft Fabric Git integration is now available. Allowing you to perform scenarios like the one below with multiple workspaces.

Which is very similar to the Azure DevOps alternative that I shared in a previous post about working with Microsoft Fabric Git integration and multiple workspaces.

I know the option to work with GitHub has got a lot of people excited. Which I why wanted to share my initial thoughts about security with you all. Because a lot of things have come to mind whilst testing this.

I want to highlight immediate implications and options before you all get too involved with testing. To make sure you test working with GitHub safely.

Plus, this post is really useful for those of you looking to test this in a regulated GitHub Enterprise environment. Because it will allow you to explain things to your GitHub administrators better, and/or forward them this post. To explain what you want to achieve.

For those wondering, I cover GitHub Enterprise in a bit more later in this post.

By the end of this post, you will know my thoughts based on my GitHub experience. In reality, a lot of the points here can be applied to other GitHub repositories you work with as well. Along the way I share plenty of links.

If you need help with any jargon used in this post, you can read my other post. Which is a Microsoft Fabric Git integration jargon guide for Fabricators.

GitHub private repositories for Microsoft Fabric Git integration

First of all, I highly recommend testing with GitHub private repositories. Especially if you are using your personal GitHub account.

Even when working with GitHub free for personal accounts you can do still a lot in private repositories. For example, you can add other contributors to your personal GitHub repository.

It can be tempting to create public repositories instead to take advantage of features such as code scanning. But it is a big security risk in doing so for various reasons. Which is why some of you will notice this option disabled if testing in your work environment.

All it takes is one commit of the wrong information and you can end up doing a lot of work. Because you will need to do more than a revert if anything is inadvertently committed.

In fact, GitHub takes this so seriously that they produced a guide on how to remove sensitive data from a repository.

Working with private repositories will be mandatory for some of you testing this with GitHub Enterprise. Which leads me to my next point.

GitHub Enterprise

Most people tend to associate GitHub with the versions that involve personal GitHub accounts. However, you may be surprised to learn that there are multiple types of GitHub products available. Not just for personal use but for enterprises as well.

Ranging from GitHub free for personal accounts for personal accounts to GitHub enterprise for a full-scale enterprise solution.

GitHub Enterprise comes with a large range of enterprise features. Such as GitHub Advanced Security. Which includes advanced security features such as both code and secret scanning.

Secret scanning is great. Because it can detect certain types of secrets like storage account keys in your repository and prevent them from being committed.

Anyway, make sure you test with a GitHub repository in GitHub Enterprise if you have the option. That way you can ensure the repository is in-line with your company’s security policies.

If you are fortunate enough to have your own Fabric tenant as well, then feel free to test there first with a GitHub personal account. However, I strongly recommend afterwards testing within your with GitHub enterprise within your work environment as well.

GitHub Personal Access Token strategy

When testing GitHub support for Microsoft Fabric Git integration within a team you must consider a realistic GitHub personal access token strategy. Especially if you must adhere to auditing or regulation rules.

Otherwise, every commit will appear to have been done by the same individual in GitHub. As I showed in my previous post. Where I covered additional security tests when using GitHub for Microsoft Fabric Git integration.

One potential option is to work with the branch out strategy that I covered in my last post. Like the below diagram.

You can look to extend the above suggestion as well. By adding additional workspaces or continuous integration checks.

For example, the continuous integration tests I covered in a previous post. Which utilizes Tabular Editor 2 to test the semantic model and PBI-Inspector to test the Power BI report.

Permissions within Microsoft Fabric

It is recommended good practice to set the correct roles within a Microsoft Fabric workspace. Especially the roles which allow people to modify the gateway settings.

However, I suggest reviewing who has access to the connection in the “Manage Connections and Gateways” section as well. You can do this by clicking on the ellipsis (…) next to the connection name and selecting “Manage users”. Which takes you to the below section.

Taking it one step further, you can also look to change the privacy level by clicking on the ellipsis and then the “Settings” option.

Working with GitHub Actions

To mange expectations, I am not doing a full introduction to GitHub Actions here. For now, I will simply state it is how you manage deployments and automation in GitHub. Similar to Azure Pipelines in Azure DevOps.

You can view an example of GitHub Actions working in another post that covers how to deploy a dacpac to a serverless SQL pool using GitHub Actions.

Anyway, if you intend to use GitHub Actions for more complex deployment scenarios with your Microsoft Fabric there are a some immediate points that sprint to mind.

First of all make sure you get familiar with secrets when working with GitHub Actions. Which you can think of along the lines of variables in Azure DevOps. Because you should store sensitive information in secrets instead of in code.

In addition, you may want to enhance the level of security for your workflows by implementing OpenID Connect.

Plus, store the majority of your secrets in Azure Key Vault instead and access them with Azure CLI. Which is covered in a blog post that shows how to read secrets from Azure Key Vault in your GitHub Action.

In addition, I highly recommend you work with environments in your repository where possible. So that you can do put in an approval process by adding required reviewers. Plus, configure rules for deployment branches and tags.

Final words about security considerations when using GitHub with Microsoft Fabric Git integration

I hope my initial thoughts about security considerations when using GitHub with Microsoft Fabric Git integration has made for an interesting read.

In reality, I could have gone into a lot more detail about security options in GitHub. However, my main focus was to make sure everybody was aware of some immediate implications and options before going too far with testing.

Of course, if you have any comments or queries about this post feel free to reach out to me.