[Feature Request]: Add support for ServiceLinker

[davidkarlsen]

Description

it would be nice to have module(s) for https://learn.microsoft.com/en-us/azure/templates/microsoft.servicelinker/2022-01-01-preview/linkers?pivots=deployment-language-bicep

[AlexanderSehr]

Hey @davidkarlsen thanks for raising the suggestion. If you have any IP already available, we welcome any contribution ;)

[davidkarlsen]

@AlexanderSehr something like this:

a bit opinionated for internal use, could be more parameterised for CARML It needs to live under the target resource, and only relevant for app services for the time being TBH. One thing I find strange though is the scope on the resource itself - but docs don't say much about it.

@description('Name of the serviceLink')
param name string

@description('Name of the target app service')
param appServiceName string

@description('ResourceId of the keyvault')
param keyVaultId string

@description('Authentication information for auth to target service')
param authInfo object

@description('Configuration info on how to map into env vars')
param configurationInfo object

@description('The resourceId of the target service')
param targetServiceResourceId string

resource appService 'Microsoft.Web/sites@2022-09-01' existing = {
  name: appServiceName
}

resource serviceLink 'Microsoft.ServiceLinker/linkers@2022-11-01-preview' = {
  name: name
  scope: appService
  properties: {
    authInfo: authInfo
    clientType: 'springBoot'
    scope: appService.id // why is this needed if it is an extension resource?
    secretStore: {
      keyVaultId: keyVaultId
    }
    targetService: {
      type: 'AzureResource'
      id: targetServiceResourceId
    }
    vNetSolution: {
      type: 'privateLink'
    }
    publicNetworkSolution: {
      action: 'optOut'
    }
    configurationInfo: configurationInfo
  }
}

[AlexanderSehr]

Hey @davidkarlsen, it has been a whle. Please note, since last September, we've been migrating all modules as per the AVM (Azure-Verified-Modules) specs to AVM-modules that are published in the Public Bicep Registry. This repository in turn will 'only' be continued as a CI for inner sourcing.

That being said, the request is absolutely legit, and I'd invite you to create a module proposal here.

Will close the issue for CARML though :)