Skip to content

Questions / Suggestions #21

@pmatthews05

Description

@pmatthews05

Hi @ykuijs
First of all, I want to thank you for putting these Repos together, you have saved a lot of time for us to get up and running.

I have a few questions, which might be due to missing it in the documentation, or just not quite understanding. I didn't know the best way of putting these questions to you, so I thought I would just raise a github issue.

I also have suggestions which I've added after the questions. Happy to make any suggestions separate git issues if accepted to be able to make a PR request easier.

Questions

  1. If deploying from a Single DevOps project for Multiple Tenants, is it expected to have 1 single tenant that holds all the certificates and secrets (for all workloads Applications in other tenants). Wouldn't it be better to have each tenant holds a key vault that holds it's own Certificates/Secrets for the App Registrations? Otherwise you have a centralised access of attack, which if compromised, access to all tenants are available. (We work with customer tenants, and not purely using this in a Dev, Staging, Test, Production design).

  2. Are there any plans on converting this to run from GitHub instead of/as well as ADO? With About Azure private networking for GitHub-hosted runners in your organization available, you can deploy into your Azure environment, like Managed DevOps pools.
    Using this directly from GitHub instead of AzureDevops will also make updates from your main repo easier via forking.

  3. In the DataFiles -> Environments what are the .envs files for?

  4. Is there a way to use Microsoft365DSC to export an environment, and convert it to the json psd1 files?

Suggestions

  1. The connection between Azure DevOps and KeyVault/Storage account can be done with a Federated Identity. This would be one less Certificate/Secret to worry about expiring.

  2. The Email AppId and Secret (Especially the secret) shouldn't be in the Variables.yaml file, this should be secure in a Key Vault. Again, with the App ID and Secret a person can use it to send Email from anyone in the tenant to anyone else.

  3. Could the Email address be extended to allow to be sent to a multiple of people. This scenario is where we handle customer tenants, and they would like an update regarding just their tenant.

  4. The Teams Webhook to be able to send to different Teams dependant on Tenant, again this scenario is where we handle customer tenants. We should get notified in our DevOps Teams channel, and be able to update the customer in their Tenants Team Channel.

  5. A separate variables-[env].yaml file for each tenant to obtain different pipeline variables. This would allow separating out the Certificates/Secrets for each tenant (Question 1), it would allow to call the relevant AzureSubscription, email/teams webhook to the customer tenant. A global variables file could exist to obtain cached modules from a centralised location, the Devops Emails, and Teams Webhook.

  6. Can the Email/Teams Message give a bit more detail of what doesn't match, e.g, the property that doesn't match, not just the section.

  7. On the pipelines when the checkout of Data and CICD repositories, it sets the path to ./s/Data and ./s/CICD, however the instructions on 4.7.1 says download the repos to c:\src\M365DSC_Data and c:\src\M365DSC_CICD, however if you then attempt to debug any of the PowerShell files from “M365DSC_CICD\scripts” locally will fail when it tries to obtain the “WorkingDirectoryData” because it’s looking for ....\Data instead of ....\M365DSC_Data. This requires an update to all PowerShell files where it's reference ....\Data to be able to run it locally to test, but unable to check those files in as it would break the pipelines.
    A suggestion would be update the instructions be aligned so that the clone is to c:\src\Data and c:\src\CICD or the pipelines path be ./s/M365_Data and ./s/M365_CICD

  8. Lastly I work in an environment where our development machines are locked down, we are unable to run as an administrator, is there a possibility to change scripts so that they are not relying on #Requires -RunAsAdministrator?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions