Best Authentication for Pipelines

[shurick81]

Hi, thank you all the contributors of this community!

I wonder what might be the best way to authenticate for using PnP.PowerShell from pipelines (for example, Github actions). I created a custom app registration and gave it proper "Application permissions" and when I run Connect-PnPOnline -Url https://sapozhkovtest18-admin.sharepoint.com -ClientId 8b965d9e-d55d-4984-ab2c-1296a81650cf -ClientSecret slkdjfslkjdhf I get this message:

Connecting with Client Secret uses legacy authentication and provides limited functionality. We can for instance not execute requests towards the Microsoft Graph, which limits cmdlets related to Microsoft Teams, Microsoft Planner, Microsoft Flow and Microsoft 365
 Groups. You can hide this warning by using Connect-PnPOnline [your parameters] -WarningAction Ignore

What are the options really for running any background application based on PnP.PowerShell?

• User and password is not good because of MFA and because user accounts in AD are not really designed for authenticating applications
• app registration with certificate might be working but then I need to feed my app not just a string but entire certificate contents, which might be a bit tricky in pipeline: I will probably need to store the certificate somewhere separately from the pipeline engine (Azure KeyVault) and read it from the pipeline. Cannot see in what way this is safer but definitely more complex for developers.
• app registration with client secret, seems to be legacy? Is it legacy because it is decided by PnP team or MS? :)

Please share your thoughts

[gautamdsheth]

hi @shurick81 , app secret has been set as legacy by Microsoft.

You can refer to these links:

https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs

and

https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly

What I do is use the 2nd approach. We store a self-signed certificate in the repo and use that in pipelines. We can also use a AzKeyVault like you suggested.

But, if we use AzKeyVault, we can also store the username/password there as well :)

It always depends.

[MHebes]

As a rule of thumb you probably shouldn't be storing credentials in a repo

[shurick81]

Is there a clear statement from MS that they consider this approach legacy?

[AndersRask]

Base64 encoded certstored in key vault is probably what you want in that scenario. For runbooks in automation accounts you can install cert and use thumbnail with key vault as another option fre. 16. jun. 2023 20.53 skrev MHebes ***@***.***>:

…

As a rule of thumb you probably shouldn't be storing credentials in a repo — Reply to this email directly, view it on GitHub <#2147 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMTDTV6YMZJ6RY2KCYFNILXLSTTRANCNFSM53SEN6EA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[shurick81]

If to store the cert in an Azure key vault, then the pipeline will need another identity to even access this keyvault, which is viable of course, but kind of overkill?

It should be possible to store the base64 encoded cert in the pipeline secrets maybe? Github actions secrets, for example, are limited to 48 KB in size.

[AndersRask]

Use managed identity to grant access to key vault søn. 18. jun. 2023 22.14 skrev Aleksandr Sapozhkov ***@***.***

…

: If to store the cert in an Azure key vault, then the pipeline will need another identity to even access this keyvault, which is viable of course, but kind of overkill? It should be possible to store the base64 encoded cert in the pipeline secrets maybe? Github actions secrets, for example, are limited to 48 KB in size. — Reply to this email directly, view it on GitHub <#2147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMTDTXMZ55W2J677OURDXDXL5OSTANCNFSM53SEN6EA> . You are receiving this because you commented.Message ID: ***@***.***>

[shurick81]

right, so deployment pipeline should "know" the secret for using managed identity, that has access to the keyvault where we store the certificate for the identity that can be used by PnP.PowerShell :)

[AndersRask]

You asked for the best way, not the easiest way 😂 søn. 18. jun. 2023 23.17 skrev Aleksandr Sapozhkov ***@***.***

…

: right, so deployment pipeline should "know" the secret for using managed identity, that has access to the keyvault where we store the certificate for the identity that can be used by PnP.PowerShell :) — Reply to this email directly, view it on GitHub <#2147 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMTDTTOUST4HVX7BHH2SKLXL5V6DANCNFSM53SEN6EA> . You are receiving this because you commented.Message ID: ***@***.***>