Allow policy id to be generated during apply

[p1johnson]

It is not possible to apply creation of a policy definition without specifying the "id" property in the policy.json file. As the policy id includes either the subscription id or management group id, this means they need to be stored in the repository. This means it is not possible to create a generic set of policy definitions that can be deployed to multiple repositories.

It would be nice if the subscription id or management group id could be specified as a parameter and the policy id generated by combining this with the "name" property from the policy.json file then we can avoid hard-coding subscription or management group ids in the repository.

[JBrashko]

Is there a MS style guide for how parameters or other preprocessing should be handled? I have some time allocated to be able to work on this and would like to ensure that any changes I raise would be in keeping with the MS code style.

[p1johnson]

Thanks for taking the time to look into this @Meliarion . I'm afraid I'm no expert on Microsoft coding practices, so I'm hoping @tauhid621 might be able to advise.

[tauhid621]

@p1johnson In my opinion policy.json is the source of truth and should have the hardcoded values.
In case there is a need for parameterised support we can define a new file format which supports parameters.

@Meliarion We do not have specific guidelines on how parameters and preprocessing should be handled. You can follow same format used in the existing code.

[JBrashko]

How exactly would you envision a parameterised policy working? Instead of having a policy.json file in the directory having a parameterised_policy.json file? Also as being able to deploy one set of policies to multiple tenants is a big requirement for my organisation I would like to get started on defining how we can support the kind of parameterisation that would be needed to make that possible.

[JBrashko]

Also some way of being able to tie inititive definitions to policy definitions that are both defined in code would be nice.

[tauhid621]

@Meliarion parameterised_policy.json sounds good. We would also need to define how these parameters are needed to be filled. How about a parameter.json file which holds all required parameter values?
We will also need to handle parametrised policy assignments.

Regarding initiative definitions ? You mean parameterised initiatives?

[JBrashko]

I imagine that these parameters would get filled dynamically from the input to the action - perhaps as a pseudomap supplied as an input. That way I can reuse as much code as possible between different deployments. Having seperate parameter files would be less ideal but still workable provided that I can supply the filename as an input to the action.

At the moment the policyset definition requires a policyDefinitionId to specify the policy, however if it is a custom policy definition then we are deploying that policy as part of this action and it would be nice to have some way to refrence the id without having to explicitly supply it.

[github-actions]

This issue is idle because it has been open for 14 days with no activity.

[tauhid621]

@Meliarion Yes, a new input can be added but it will be limiting. Perhaps a combination of an environment input and a parameters json will be best?

I believe you can modify the place where we fetch the definition/assignments json. We can have a getPolicyJson function which will get the json file then based on inputs it will substitute.

For policyset, I get your point. maybe it can be done in similar parameterised way?

[tauhid621]

Closing this as this has been open since a long time. Feel free to create a new issue if required.