Ignore Key Vault Secrets after initial create

[ianphil]

Description

As an engineer, I'd like to ensure that the secrets in key vault can change from outside of TF and not have TF recreate them, in order to allow for key rotation.

We should add the ignore lifecycle [or something similar] to these items and possibly the AD SP/App Registration items. We probably will need to look deeper into this and how the two interact.

Examples:

• App Service Secrets
• ACR Secrets
• ACR Password

Thoughts:

• This should create these secrets on first run.
• All subsequent runs it should ignore them as they are always used and could be changed by an organizations key/secret rotation strategy.
• App registration will probably need to be treated similarly. And another set of stories should be created if that is the case.

Acceptance Criteria

Reference: [Done-Done Checklist] (https://github.com/Microsoft/code-with-engineering-playbook/blob/master/Engineering/BestPractices/DoneDone.md)

• Should only ever create the secrets once
• Should not affect the AD App Registrations lifecycle
• Should not affect the AD Service Principle lifecycle

Also, here are a few points that need to be addressed:

1. Constraint 1;
2. Constraint 2;
3. Constraint 3.

Resources

Technical Design Document
Mockups

Tasks

Stories are intended to be completed in a single sprint; if task breakdown creates addition work then team should discuss promoting the Story to an Epic.
Reference: [Minimal Valuable Slices] (https://github.com/Microsoft/code-with-engineering-playbook/blob/master/Engineering/BestPractices/MinimalSlices.md)

Reference: [How to Write Better Tasks] (http://agilebutpragmatic.blogspot.com/2012/04/splitting-story-into-tasks-how-to-write.html)

Assignee should break down work into tasks here