Additional security tests when using GitHub for Microsoft Fabric Git integration

Reading Time: 6 minutes

In this post I want to share the results of some additional security tests when using GitHub for Microsoft Fabric Git integration. Which I performed recently after being asked about a couple of topics.

By the end of this post, you will know the consequences of multiple users updating items in the same workspace with the same GitHub connection. In addition, where you can edit existing GitHub connections within Microsoft Fabric.

Plus, I show an alternative way of working with workspaces to enable proper auditing of commits in your GitHub repositories. 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.

One key point I want to highlight is that the GitHub support for Microsoft Fabric Git integration is currently in preview and the contents of this post are subject to change.

Multiple users updating the same Microsoft Fabric workspace

First, I tested multiple users updating the same workspace with the same connection. Since somebody asked me about this and I wanted to double check my answer.

With this in mind I created a new GitHub account with a different picture of myself to visualize the results better. I then added the new account as a collaborator to the repository that I created in my previous post. Which covered my initial tests.

Even though I performed the commit as a different user in Microsoft Fabric in GitHub it still showed that the account I created the personal account token with did the commit.

Which shows that GitHub will always show the owner of the personal access token as the person who done the commit. Regardless of who performs the change in Microsoft Fabric.

Testing a GitHub personal access token for the new user

I then decided to create a personal access token for the new user. Because they are a collaborator in my private repository a fine-grained personal access token is not an option. Due to the fact I cannot select an individual repository for them.

I had to create a classic personal access token for the new GitHub account instead. Afterwards, I then went back into workspace settings in Microsoft Fabric to add the details about the personal access token.

To clarify, there are a couple of different ways that I can add the new personal access token in the workspace settings when an existing connection exists. For example, I can go select “Add account” in workspace settings to add a new connection with the new personal access token.

However, another member of the community recently mentioned that they could not delete their connection whilst testing GitHub. With this in mind, I decided to show another method that highlights where you manage the GitHub connections.

You can do this in workspace settings by clicking on “Manage all accounts”.

Clicking this option takes you to the “Manage Connections and Gateways” settings in Microsoft Fabric. Which can also be accessed via settings.

Here is where you manage your GitHub connections. Because I wanted to change the personal access token I clicked on settings. I then scrolled down to authentication and changed the personal access token to the new one.

After saving the change I went back and changed the description of the report again and committed the change. I then went back into GitHub where it now showed that a commit had been performed with my alternative account.

Viable solution when using GitHub for Microsoft Fabric Git integration

Clearly changing the personal access token in the same workspace every time somebody else wants to commit a change is not a viable solution for multiple users.

However, you should strive to show exactly who performed the changes in GitHub. In fact, this is mandatory for a lot of enterprises and auditing standards.

One way to resolve this is to copy the existing workspace in Microsoft Fabric to a new one that uses a different branch in the same Git repository.

You can then create a new connection to GitHub in the new branch with an alternative personal access token. Afterwards, you can create a pull request to synchronize the two branches when an update is required.

GitHub Security test with two separate workspaces and branches

To test this, I created a second workspace which worked with a different branch. I did this in the original workspace by selecting the “Branch out to new workspace” option in Source control.

Which allowed me to create a new workspace that connected to a new feature branch.

I then went back to my original development workspace and added a new connection that referenced the personal access token for original GitHub account. To ensure the two workspaces referenced personal access tokens for two different GitHub accounts.

Afterwards, I went into the new workspace that was connected to the feature branch and changed the description of the report again. Which I then committed in source control.

Once completed, I went into GitHub and created a pull request from the new feature branch to the dev branch.

Once I had completed the merge request and merged the feature branch to the dev branch I went back into the original dev workspace in Microsoft Fabric. Which recognized the change.

Which shows that you can have two workspaces connected the same GitHub repository using two separate personal access tokens.

However, if you decide to go for a similar setup, I recommend putting in some additional security measures in place. For example, create a ruleset to enforce pull requests on whichever branch you intend to merge.

In addition, you need to ensure that the relevant security is configured in Microsoft Fabric to allow for this to be done.

Final words about my additional security tests when using GitHub for Microsoft Fabric Git integration

I hope the results of my additional security tests additional security tests when using GitHub for Microsoft Fabric Git integration has made for an interesting read.

In addition, I hope it has made some of you aware of the implications of working with the same personal access token for multiple users.

I really like the fact that we can work select GitHub as a provider for Git integration now. However, as you can see there are various security implications to consider when using GitHub as a provider for Microsoft Fabric Git integration.

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