Winterdom

Azure File Storage and Billing Transparency

Wed, 11 Dec 2019 00:00:00 +0000

Azure Files is an excellent service, providing file-system (SMB) based storage on the cloud. It has been very useful for us together with Azure Kubernetes Service.

Functionality-wise, I have no complaints. While there are a few things that could be better, the service overall provides good value, and the addition of Premium File Storage is definitely a very interesting and exciting option.

I have been, however, dissatisfied with the Billing experience.

Cloud Billing Transparency

I’m a strong believer that Cloud-based offerings need to have a clear set of billing rules that customers can clearly understand and use to budget their cloud costs. There are 4 key elements that I believe contribute to having clear and transparent cloud billing for usage-based services:

The publicly available pricing information should clearly document what billing meters are used and how these relate to the prices listed.
For services that charge for communication, any related billing meters should have a clear relation to the underlying protocol operations and semantics.
The service should provide metrics that allow customers to understand their usage.
Any metrics should clearly relate to the corresponding billing meters, so that the customer can audit their bills for accuracy.

A customer that understands how your service is billed, budget properly for it, and also audit the usage is a happy customer.

The Azure Files Billing Conundrum

Why am I generally unhappy about how Azure Files are billed? It’s not so much that I object to the actual cost of the service (which is generally reasonable for most scenarios), but that I believe that Azure Files breaks several of the rules above.

Let me explain why.

Pricing Information vs. Billing Meters

The first issue I have with Azure Files is how pricing information is presented. There are two separate components: Storage and Operations.

Storage pricing is very clearly presented, but Operation pricing is very deceptive.

Billing meters are only partially related to how pricing is presented. While pricing talks about “Put, Create Container Operations” or “List Operations”, billing meters include things such as “protocol operations”, and “lrs write operations”. You can guess about how they are mapped in some cases, but not all of them.

I would much rather the pricing information was presented by outlining the meters used and what each one measures exactly.

Billing and Protocols

Azure Files operation pricing is stated in terms of the underlying operations on the REST API. This is fine if you’re accessing the service over the HTTP interface, but that’s not really the common usage for Azure Files.

Instead, you’ll mostly be accessing the service over SMB from Windows or Linux machines, and so there’s no clear relationship of how a File-System-based operation (such as Open File) maps to an operation on the REST API. This leads to significant confusion and makes it easy to budget incorrectly for the service, understimating the actual costs.

For example, I ran into a case where a service would often open a file, read from it, and then close it. I was pretty surprised that my Azure Files bill was primarily composed of “Write Operations”. Well, surprise-surprise, turns out that the file-system open a file operation is considered a write operation for billing purposes. There was absolutely no way for me to figure that out before I wasted a lot of time and a few support cases (which went nowhere) on it.

Meters and Metrics

Azure Files supports some basic metrics, which get stored in Azure Storage Tables on the same storage account. While these are useful in general, they are not very useful to audit your usage costs.

This is because the metrics, again, bear no direct relationship to the billing meters. For example, you will see things like this in your storage metrics:

user;Create
user;SessionSetup
user;Write
user;GetFile
user;QueryInfo
… and more

These bear a little bit more relationship to the file-system semantics of Azure Files access over SMB (but still only partially). The big problem is that there’s no obvious way to relate the metric values to the corresponding Billing Meters being used. We can guess about what some of it means, but since it’s essentially undocumented, it does not provide a base that’s stable enough to actually audit your bill.

It also clearly doesn’t relate very clearly to the public pricing information, either.

But beyond the obvious disconnect with pricing/meters, there’s an even more annoying issue with Azure Files metrics: They don’t provide enough information to actually troubleshoot billing issues, because there are no corresponding access logs for Azure Files.

So if my Azure Files bill grows 10x in write operations, there doesn’t appear to be a way to figure out what shares, folders, or files are actually getting accessed and thus triggering the usage increase. Even Microsoft Support appears unable to obtain this information, which means that if you run into such a case, you’re stuck trying to figure things out by trial and error.

Conclusion

While Azure Files provides an excellent platform for cloud services, make sure you understand exactly what your usage patterns are and keep in mind that the file-system nature of the service seems to be very much at odds with how the pricing information is presented. Expecting some surprises in your bill while you understand your usage patterns better might be a good idea, too.

Importing Certificates into Azure Key Vault using the API

Thu, 31 Oct 2019 00:00:00 +0000

I spent some time the last two days figuring out how to correctly import X.509 certificates into an Azure Key Vault instance using the API (through the Microsoft.Azure.KeyVault NuGet package), and ran into a few issues.

Unfortunately, neither the library, nor the underlying REST API are very well documented, so wanted to write this post to document the gotchas I ran into, in case it’s useful to anyone.

PEM Certificate Format

The Import Certificate API (and corresponding KeyVault.ImportCertificate() method) are documented as accepting the certificate to import in both PFX and PEM formats. It took me a while to figure out the right incantation to use for a PEM file, however.

There are a few separate issues here you need to be very careful about:

Private Key Format: A certificate with a private key in a PEM file could have the key stored in various format. One very common one is PKCS#1, which is identified by the key being wrapped in -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY-----.

If you try to import such a certificate to Key Vault, however, you will get an error. This is because Key Vault will only accept a key in PKCS#8 format, which you will recognize because it’s wrapped in -----BEGIN PRIVATE KEY----- and -----END PRIVATE KEY-----.

You can easily use the openssl pkcs8 -topk8 command to convert the private key once you know to do this.

This aspect is not documented on the API, but it is mentioned in passing in the (Key Vault documentation)[https://docs.microsoft.com/en-us/azure/key-vault/certificate-scenarios#formats-of-import-we-support].

Content Type: If you’re going to import a PEM certificate, you also need to set the policy.secret_props.contentType property to the right type:

var policy = new CertificatePolicy {
  SecretProperties = new SecretProperties {
    ContentType = "application/x-pem-file"
  }
};

Value Format: The second confusing part I ran into here is how to actually send the PEM data to KeyVault. The API documentation states that the value parameter is Base64 encoded representation of the certificate object to import. This is only partially correct.

If you’re importing a certificate in PFX format, this is correct. PFX is a binary format, so you need to base64-encode the value before providing it to Key Vault. PEM, however, is already a text format, so base64-encoding it will make no sense.

The result is that the value parameter will just be the raw text contents of your PEM file. With one major, undocumented gotcha: The content must use UNIX-style line separators (\n). Attempting to send the content using Windows-style line endings (\r\n) will just result in a confusing error such as The specified PEM X.509 certificate content is in an unexpected format. Please check if certificate is in valid PEM format.

The only way I was able to figure out this little detail was by reading the Azure CLI source code.

Updating Certificates

Another interesting scenario I ran into was attempting to import a new certificate version on top of an existing certificate as a new version. The documentation for the Import Certificate API doesn’t actually say if this is possible, but since the Azure Portal actually allows you to do it, I figured it would be a safe bet that it would work.

It is, indeed, possible to do this. However, there was one surprising error I ran into while testing this out.

Purely by coincidence, I tried importing a certificate that had a 4096-bit key as a new version of a previous certificate that had a 2048-bit key. Trying this out failed with a CONFLICT error. Digging deeper, I found out that the actual error message was Expected KeySize is 4096 but was 2048.

This made no sense at first, until I realized that Key Vault was apparently attempting to somehow reuse the key of the current certificate version rather than the one included in the Import Certificate call.

The way to avoid this error appears to be to explicitly set the policy.key_props.key_size parameter to the right value when attempting to import the new certificate version on top of the old one:

var policy = new CertificatePolicy {
  Attributes = new CertificateAttributes {
    Enabled = true
  },
  SecretProperties = new SecretProperties {
    ContentType = "application/x-pem-file"
  },
  KeyProperties = new KeyProperties {
    Exportable = true,
    ReuseKey = false,
    KeySize = theCertificate.PublicKey.Key.KeySize
  }
};

Hope you find this useful!

Defining RBAC Role Assignments in ARM Templates

Thu, 02 Aug 2018 00:00:00 +0000

It’s no secret I’m a big fan of Azure Resource Manager (ARM) templates. Getting started with ARM templates is hard, but well worth the effort, and make it significantly easier to have reproduceable, consistent deployments of your Azure resources.

One thing that I had been feeling left out, however, was being able to assign permissions to Azure resources during creation. Azure’s Role-based Access Control (RBAC) mechanism is a powerful way to control who can manage and access your resources, and having to do this through scripting was possible, but cumbersome at times.

A few days ago, I realized that you can actually create RBAC role assignments through ARM templates just like any other resource. This capability is not new by any means, I just had missed it before!

Creating an assignment

To create an assignment, you need the following information:

The ID of the role you want to assign. This is a long string that contains the subscription id and the role identifier (both GUIDs).
The object ID of the user/group/service principal you want to grant access to.
The scope at which you want to assign the role, which is going to be either a subscription, resource group, or resource id.

Here’s an example of creating such an assignment:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": { 
    "monitoringUsersGroup": {
      "type": "string",
      "metadata": {
        "description": "Object ID for the monitoring users group in AAD"
      }
    }
  },
  "variables": {
    "monitoringContributorRole": "[concat(subscription().Id, '/providers/Microsoft.Authorization/roleDefinitions/749f88d5-cbae-40b8-bcfc-e573ddc772fa')]"
  },
  "resources": [
    {
      "type": "Microsoft.Authorization/roleAssignments",
      "name": "ace492e6-ebf6-48fa-8dd4-ea762489cbf3",
      "apiVersion": "2017-10-01-preview",
      "properties": {
        "roleDefinitionId": "[variables('monitoringContributorRole')]",
        "principalId": "[parameters('monitoringUsersGroup')]",
        "scope": "[resourceGroup().Id]"
      }
    }
  ],
  "outputs": {}
}

Here we grant the members of an Azure Active Directory group the Monitoring Contributor built-in role to the resource group the template is deployed to.

Also interesting here is that you don’t need to specify a location property in the resource.

Some gotchas

There are a couple of things to watch out for when doing this.

The first one is that to assign a role, you need the objectId of the AAD user/group/principal, rather than the name. This is cumbersome because there’s no way to resolve these within the ARM template itself, so you’ll always need to pass these as input parameters.

A more significant issue, however, is the name of the roleAssignment resource, which needs to be a unique GUID.

This is a problem if, for example, you’re assigning role permissions at the resource group or individual resource level, rather than globally at the subscription.

For example, in my case I was creating a template that would be used to deploy multiple copies of the same resources into different resource groups within the same subscription.

If the GUID that defines the role assignment name is hardcoded in the template, then each time I ran the template, the scope of the role assignment would get overwritten with the id of the last resource group it was deployed to. Clearly, this is undesirable.

What we need then, is a way to ensure that each deployment to a different resource group uses a different GUID for the role assignment, but at the same time, ensure that the same one is used when deploying to the same resource group.

Clearly, providing the assignment GUID as a parameter is an easy workaround, but very cumbersome.

A better workaround comes from the guid function! It takes one or more strings that are used to calculate a hash, very much like the uniquestring function; only this one generates a string in GUID format instead.

By using the guid function with the resource group id and some other consistent stuff as input, we can solve our problem in an elegant way:

    {
      "type": "Microsoft.Authorization/roleAssignments",
      "name": "[guid(resourceGroup().id, 'monitoringUsers')]"
    }

Issues when deleting azureFile dynamic volumes in Kubernetes

Thu, 26 Jul 2018 00:00:00 +0000

I’ve been doing a lot of work lately with Kubernetes and Azure Kubernetes Service in particular. For this, I’m using the azureFile storage provider to support providing storage folders for my pods.

For one specific case, I’m using dynamic provisioning of persistent volumes, as described in the documentation. This has been working great. Almost.

Today I noticed something odd. Some of the Persistent Volumes created were stuck on a failed state during deletion:

The error message was this:

Failed to create deleter for volume "pvc-85ba62d5-902e-11e8-9771-2a03d0b14ac3": Couldn't get secret 6d07576ce8d89bd641b5/azure-storage-account-fd9063993902011e888c32e-secret

This actually made sense. The way dynamic persistent volumes work is this:

When the Persistent Volume Claim is created, Kubernetes creates a new Secret object containing the credentials for the Azure Storage Account. This secret is named azure-storage-account-<namespace>-secret.
When the Persistent Volume Claim is deleted, the deleter for the volume will use these credentials to delete the Azure File Share that was dynamically created, and then delete the corresponding secret.

The second part is what was biting me.

I currently deploy the applications using Helm. I deploy each one into a separate Kubernetes Namespace. This is fully supported by Helm, but has one issue: When you delete the application using helm delete, the original namespace created remains behind. I wanted to clean these up, and so was aggressively deleting them using kubectl delete namespace.

The problem here is that the secret that gets automatically created by the azureFiles provider when the Persistent Volume Claim is created, goes into the same namespace as the PVC. That meant that when I was aggressively removing the namespace, I was also deleting the secret before the volume deleter could get to it.

This isn’t very clearly documented (or at least I found no mention of this), so it might be something to watch out for.

AzureFile Persistent Volumes Retain Issue

Thu, 26 Jul 2018 00:00:00 +0000

A bit ago, I posted about some issues around permissions when using static provisioning of Azure File volumes in Azure Kubernetes Service (AKS). In there, I mentioned that the workaround was to use explicit Persistent Volumes so that the right mount options could be created.

Since then, I’ve run into a separate, but related, issue. I started noticing that sometimes, my Persistent Volume Claims would get stuck on the PENDING state:

The notes for the PVCs would not contain any useful information. But looking at the Persistent Volumes, I noticed they would get stuck in the RELEASED state:

I could not figured out exactly what was happening until I noticed the pattern that led to it:

I’d create the Persistent Volumes
Then I’d deploy an application on the cluster that would create Persistent Volume Claims on the volumes
I’d update the application. This worked just fine and stuff continued to run.
I’d remove the application (thus deleting the Persistent Volume Claims)
I’d deploy the application again, and now the PVCs would get stuck in Pending state.

The issue of course, happened in step (4) above. Once the Persistent Volume Claim was deleted, the Persistent Volume would transitioned to the Released status. These volumes all had a default reclaim policy of Retain.

Based on my understanding, I would have expected that taking a new claim on the volumes would work. But unfortunately, this does not appear to be the case (either I’m misunderstanding the Kubernetes documentation, or there’s an issue here in the volume provider).

I also thought that maybe making this work would involve setting the retain policy to Recycle, but this appears to be unimplemented as of yet for the azureFile provider.

In any case, once this happens, the only way to get this working again is to manually delete the Persistent Volumes and recreate them again from scratch.

This is unexpected (not explicitly documented), not obvious, and certainly annoying.:w

AKS Service Principal Credentials

Tue, 24 Jul 2018 00:00:00 +0000

When creating a new Azure Kubernetes Service (AKS) cluster, you must define a Service Principal in your Azure Active Directory Tenant that will be used by the cluster to do operations on the Azure infrastructure later on.

The documentation states:

On the master and node VMs in the Kubernetes cluster, the service principal credentials are stored in the file /etc/kubernetes/azure.json

I was curious how this worked, so I set out to take a look at the file. An easy way to do this was to spawn a new busybox pod on the cluster with the azure.json file mounted as a volume into the container.

I used the following YAML template to create the pod using kubectl apply:

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: busybox
    command:
      - sleep
      - "3600"
    volumeMounts:
      - mountPath: /etc/kubernetes/azure.json
        name: azure-secret
  volumes:
    - name: azure-secret
      hostPath:
        path: /etc/kubernetes/azure.json
        type: File

Once the pod is up and running, I went spelunking into it by opening a new interactive session using kubectl exec -it test -- sh.

First, let’s look at the contents of the file through cat /etc/kubernetes/azure.json:

{
    "cloud":"AzurePublicCloud",
    "tenantId": "*********",
    "subscriptionId": "*********",
    "aadClientId": "**********",
    "aadClientSecret": "*********",
    "resourceGroup": "MC_dev-k-eastus-2-rg_dev-k-eastus-2_eastus",
    "location": "eastus",
    "vmType": "standard",
    "subnetName": "aks-subnet",
    "securityGroupName": "aks-agentpool-22088002-nsg",
    "vnetName": "aks-vnet-22088002",
    "vnetResourceGroup": "",
    "routeTableName": "aks-agentpool-22088002-routetable",
    "primaryAvailabilitySetName": "agentpool-availabilitySet-22088002",
    "primaryScaleSetName": "",
    "cloudProviderBackoff": false,
    "cloudProviderBackoffRetries": 0,
    "cloudProviderBackoffExponent": 0,
    "cloudProviderBackoffDuration": 0,
    "cloudProviderBackoffJitter": 0,
    "cloudProviderRatelimit": false,
    "cloudProviderRateLimitQPS": 0,
    "cloudProviderRateLimitBucket": 0,
    "useManagedIdentityExtension": false,
    "useInstanceMetadata": true,
    "providerVaultName": "",
    "providerKeyName": "k8s",
    "providerKeyVersion": ""
}

The relevant fields containing the credentials are aadClientId and aadClientSecret.

I was curious, however, as to the permissions on the file:

/ # ls -l /etc/kubernetes
total 4
-rw-------    1 root     root          1173 Jul 24 19:13 azure.json

As suspected, the file is only readable by containers running as root.

AKS and Azure Files Permissions

Mon, 23 Jul 2018 00:00:00 +0000

Saving this here for my own recollection later on. Warning, a bit of ranting ahead.

Recently, I’ve been running a lot of trials on top of the Azure managed Kubernetes Service (AKS). One key feature that I needed was the ability to provide services deployed to an AKS cluster with external storage. Since I needed the option to mount the storage shared between multiple pod instances, Azure Files was the way to go.

My first attempt to do this leveraged using automated static volume provisioning, as defined in the documentation. Static just means that you first create the Azure File Share on your own, and then provide the pod with the necessary information to reach it, such as the account name and key, and the file share name.

This worked, sort of. There’s a big gotcha that’s not included in the documentation, and that takes a bit of search-fu to find it.

The problem is file permissions. When using static provisioning, the Azure Files plugin in Kubernetes will default the share permissions to 0750 or 0700 depending on the version of Kubernetes in use.

What this means is that static provisioning, as described in the AKS documentation, is completely useless if the following conditions are met:

Your container is configured to run as a non-root user (which is generally the recommended approach for security), and
You need to write to the mounted file share.

If you just need to read data from the share, then this is not a problem. If you need to write to it, however, this really throws a wrench into your plans, and the documentation doesn’t tell you how to work around it.

The workaround

The workaround is described in more detail on this sample by Andy Zhang.

Create a new Kubernetes Persistent Volume for your Azure Files Share, and override the default file and directory permissions for the file share.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azurefile
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  azureFile:
    secretName: azure-secret
    shareName: k8stest
    readOnly: false
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=10000
    - gid=10000
    - mfsymlinks
    - nobrl

Create a new Persistent Volume Claim for your service to request access to the Persistent Volume created in the previous step

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-azurefile
spec:
  accessModes:
    - ReadWriteMany
  mountOptions:
  resources:
    requests:
      storage: 5Gi
  storageClassName: ""
  volumeName: pv-azurefile  

Create a volume for your pod out of the PVC.

volumes:
  - name: azurefile01
    persistentVolumeClaim:
      claimName: pvc-azurefile

Notice that the storage capacity is required on both the Persistent Volume and the Claim, and should be equal or smaller to your Azure File Share size.

The disadvantages

The documented workaround works just fine. However, the whole issue is frustrating on many levels.

First of all, making it hard to follow the recommended practice of running containers as non-privileged users makes no sense to me. This should be easy, and work right away without having to result to these complicated steps.

Second, the fact that the documentation doesn’t warn you about the issue, and doesn’t provide a link to the solution, is very frustrating, and causes you to lose a few hours for no good reason.

While I can sort of understand why restricting the default Unix permissions on the file share, it seems to me this is just a very leaky abstraction, than on a platform like AKS doesn’t make a lot of sense.

The most frustrating aspect for me, however, is the fact that using Persistent Volumes forces you to have to create those manually before you can deploy applications. If you just need to reference a single Azure File Share, then it’s sort of OK, but if you need to reference several, it quickly adds to a lot of work. You need to manually create at least 2 Kubernetes objects (a Secret, and the Persistent Volume) for each share.

I’m using Helm to deploy my application, and now I can’t simply deploy the helm chart. I need to manually create stuff, ensure it’s correct, and only then can I deploy it. This is just cumbersome.

I wish you could just adjust default permissions directly when creating the volume, but alas, apparently this is not possible with the Kubernetes model (or simply unsupported by the Azure Files plugin).

Update: Posted some additional findings here

Getting fixed!

Update 2018-11-15: Looks like this issue is finally fixed in Kubernetes v1.11.4 with the default permissions for Azure Files reverting to 0777. Great news.

AKS Node Troubles

Sat, 14 Jul 2018 00:00:00 +0000

I’ve been having lots of fun this past week running some interesting experiments on Kubernetes. For simplicity, I created a single-node AKS (Azure Kubernetes Cluster) using a B2S instance on Azure.

Everything worked perfectly until Friday afternoon. At some point, I noticed that every operation on the cluster appeared to be very slow. Even browsing the Kubernetes admin portal was an exercise in frustration. The worker node, however never went above 20% CPU.

I then tried restarting the node, which proved to be…. a mistake, as it never came back up completely.

After a while, I started noticing that when running kubectl get nodes, the node was being reported as NotReady. I didn’t have time to troubleshoot it further, so left it like that and tried again today, without much more luck.

After searching for a bit, tried doing a kubectl describe node <node>, and noticed it was reporting:

KubeletNotReady           PLEG is not healthy....

Of course, trying to find out what PLEG was supposed to be was next to impossible. I did, however, looked up the kubelet logs using journalctl -u kubelet, but didn’t see anything noteworthy there.

I then tried restarting the kubelet service which sort of worked! After about 5 mninutes the node transitioned to the Ready status, and about 3 pods came up to Running status. Unexpectedly, all 3 were user pods, and not a single one of the kube-system pods came up before the node went back to NotReady status. Again, the reported failure was PLEG is not healthy.

Conclusion

So far, I have failed to figure out exactly what triggered this issue, and how to solve the underlying issue. Heck, I’m still trying to figure out what PLEG is.

The logical thing to do would have been to nuke the node, and create a new one from scratch.

However, I couldn’t figure out an obvious way to do that with AKS. While you can easily scale your cluster to add additional nodes, it’s not obvious how to replace an unhealthy node with a new one. I’m sure it might be possible, but I didn’t spend much trying to look for it.

What did worked was upgrading the cluster. I originally created it using Kubernetes 1.10.3, and then noticed that 1.10.5 was available.

Kubernetes upgrades in AKS work by provisioning a new node, then removing the old one, and so it proved an indirect way to do exactly what I wanted, resulting in a healthy cluster again. However, I’m still scratching my head as to what happened and what exactly was failing…

Viasfora v4.0 Update

Mon, 04 Jun 2018 00:00:00 +0000

For the past few months, I’ve been slowly improving my Visual Studio Extension, Viasfora. Version 4.0 was recently released, and besides regular bug fixes and some much needed refactoring, I also implemented a brand new feature: Rainbow Lines.

For now, this feature is disabled by default, while I iron out all kinks and ensure it has the best possible performance. If you’re a Viasfora user, and like the feature, please do give it a try and let me know any feedback!

Implementing this feature was interesting. Getting the right locations and handling caret movement was relatively straightforward, particularly since it relies on the same logic that was already present to support the Rainbow Highlight feature. Drawing the lines, however, was far trickier.

The largest complexity here is the fact that the Visual Studio Text Editor doesn’t have layout information for all lines; just for those that are currently visible. So when the line containing the opening brace or closing brace is not visible, figuring out the right place to draw the lines can get tricky.

Still, I think the end result is pretty decent, particularly considering the tricks for handling scrolled views, such as this:

Of course, it’s not perfect. For example, since Viasfora does not do lexical analysis, sometimes the lines will not align perfectly with Visual Studio’s structure guides:

Themes

Version 3.6 introduced the concept of themes. These are simple JSON files that contain all the color information for the text editor classifications in Viasfora.

You can export your current configuration as a new theme, or import an existing one. I don’t think many people have been using this, but if you have customized the Viasfora color configuration extensively, I’d love to see what you’ve done with it and what works for you.

In the meantime, I’ve shared the theme I’m currently using for Rainbow Braces here, and it works pretty nicely on the Visual Studio dark theme:

Version 4.1

Since the v4.0 release, I’ve continued improving Viasfora, and version 4.1 should be coming up soon. It contains a few improvements to Rainbow Lines, but the biggest change by far was required to support changes in how Visual Studio loads extension packages.

Recently, the product team announced that Visual Studio 2017 version 15.8, Visual Studio would start alerting users when loading synchronous packages that are configured to auto load (via the [ProvideAutoLoad] attribute), and a later version would completely disable support for this.

Of course, Viasfora was one of the affected extensions, since it was configured to auto-load when the Text Editor is displayed the first time. Though the Viasfora package did very little initialization and was generally quite fast, it would be subject to the same rules as any other package.

Not wanting this to cause any issues, I set up to change this, which lead to a significant refactoring of the code. Converting the package to an AsyncPackage did not seem possible without dropping support for VS2012, but I was able to completely remove the need to auto-load the package with only a minor loss of functionality.

API Management Sign-in Tenant

Fri, 20 Apr 2018 00:00:00 +0000

Azure API Management supports multiple identity providers for the Developer Portal. One of these is Azure Active Directory. A common complaint, however, was that when enabling AAD authentication on the developer portal, the sign-in experience would use the default look-and-feel of AAD rather than your organization’s customized sign-in pages.

The reason for this is that unlike many other products and services, API Management always works as a multi-tenant application allowing users from multiple AAD tenants (the ones you configure). Because of this it always uses the common AAD sign-in URL https://login.microsoftonline.com/common rather than the tenant-specific sign-in URL https://login.microsoftonline.com/{tenant_name_or_id}. You can read more about the common endpoint in the AAD documentation.

This changed a few weeks ago on the API Management side. Looking at the release notes, we find this little note:

When configuring Azure AD as an identity provider, it is now possible to designate one of the allowed tenants as a sign-in tenant. All developer portal users will be redirected to that tenant when logging in (instead of the “common” tenant)

The new configuration property on the AAD identity provider is called signinTenant, and can be configured in the Azure Portal experience when adding (or editing) an AAD identity provider:

Note: When configuring a new provider, you need to both add the tenant ID to the allowed tenant list, and provide it in the sign-in tenant field if you want it to work.

There is also a nice side-effect from configuring the signinTenant property: Before this, using guest accounts in AAD directories, such as Microsoft Accounts (MSA) or guest B2B accounts to sign in to the API Management Developer Portal was not supported. The reason for this is that when using the common endpoint, AAD has no way to know the target directory to sign the user into.

If you set the signinTenat property, however, this now works for both MSA and B2B guest accounts on the that specific tenant. This enables a lot of useful scenarios for API Management users.