Security review

[leighatami]

Security review needed for go-public. Specifically, we need:

### Tasks
- [ ] Threat Model
- [x] Secret Scanning Enabled (GitHub Advanced Security)
- [x] Secret Store Configured (GitHub Encrypted Secrets)
- [x] Secrets Management (GitHub encrypted secrets)

[eduardodfmex]

Adding Jayce recommendations:

Here is the currently relevant links to the playbooks:

Internal: https://internal.playbook.microsoft.com/ External: https://internal.playbook.microsoft.com/ Most useful is still going to be looking directly at the repo. We just don't have a lot of content that has been moved to either published ring as of yet: cse-labs/opsplaybook (github.com) We are working on updating everything around secrets (including scanning) so it will likely be promoted soon after those edits. Downside is there are a lot of edits and moves related to how we want to handle the playbooks. So, it's going to be a longish process. Several weeks at minimum. That is currently here: https://microsoft.github.io/code-with-engineering-playbook/continuous-integration/dev-sec-ops/

If what you are after is going directly for the guidance around container, dependency, or vulnerability scanning you probably just want to go directly to the 03-Deploy section: opsplaybook/docs/code-with-devsecops/Capabilities/03-Deploy at main · cse-labs/opsplaybook (github.com).

Finally, there are still a few things that may be relevant to your work in the EFR. Take a look at the landing page for DSO Practices there. I haven't took a dive through those materials for some time, but they are still there: https://github.com/cse-labs/opsplaybook/tree/main/docs/code-with-devsecops/Capabilities/03-Deploy

[eduardodfmex]

We need to create / implement:

• We need a threat model design, document with diagram, component, threat analysis and mitigations, example: https://internal.playbook.microsoft.com/code-with-engineering/security/threat-modelling-example/#overview
• Key DevSecOps activities include threat modeling, code reviews, and automated testing.
• Secret Management

• Secrets detection: https://internal.playbook.microsoft.com/code-with-devsecops/Capabilities/02-Develop/Secrets-Detection/Recipes/Gitleaks/

• Secrets Store: https://internal.playbook.microsoft.com/code-with-devsecops/Capabilities/02-Develop/Secrets-Store/

[mattdot]

• If we already have GitHub advanced security scanning, what's the benefit of gitleaks?
• We are using GitHub encrypted secrets for any secrets needed by pipelines.
• Threat model seems like the logical next step, @eduardodfmex are you working on that?

[eduardodfmex]

@mattdot yes Im working on the Threat model, and I dig more I don't see in our action's, Secret detection and Dependency review, following more description:

Agree with the Github encrypted secrets.

Related to the Code review:

I see that the Github Advance Security covers Secret Detection and Dependency, but I don't see if we implement the review of the two Secret and dependency review.

Code Reviews by workflows Secrets Detection Solutions Playbook for DevSecOps recommend implementing [secret detection] (https://internal.playbook.microsoft.com/code-with-devsecops/Capabilities/02-Develop/Secrets-Detection/Recipes/Gitleaks/) using the Gitleaks tool, the tool requires a license, but we can implement an unofficial GitHub action that use the tool which is: [Gitleaks Scanner · Actions · GitHub Marketplace] (https://github.com/marketplace/actions/gitleaks-scanner)

Dependency Review This action scans your pull requests for dependency changes and will raise an error if any vulnerabilities or invalid licenses are being introduced. The action is supported by an API endpoint that diffs the dependencies between any two revisions on your default branch. The action is available for all public repositories, as well as private repositories that have GitHub Advanced Security licensed. actions/dependency-review-action: A GitHub Action for detecting vulnerable dependencies and invalid licenses in your PRs

I already tested the 2 actions in another repo today (simple actions with basic go code).

If we agree this Issue will cover:

• Create Threat Model documentation.
• Implement / verify Secret detection and dependency check with a second tool (listed above), I recommend investing in a second review or fine-tuning of the tools that could find security holes.
• Document the code review process that we use.

[mattdot]

@eduardodfmex reminder to close this one out this week

[eduardodfmex]

OpenID Connect (OIDC) defined

OpenID Connect (OIDC) is an identity authentication protocol that is an extension of open authorization (OAuth) 2.0 to standardize the process for authenticating and authorizing users when they sign in to access digital services. OIDC provides authentication, which means verifying that users are who they say they are. OAuth 2.0 authorizes which systems those users are allowed to access. OAuth 2.0 is typically used to enable two unrelated applications to share information without compromising user data. For example, many people use their email or social media accounts to sign in to a third-party site rather than creating a new username and password. OIDC is also used to provide single sign-on. Organizations can use a secure identity and access management (IAM) system like Microsoft Entra ID (formerly Azure Active Directory) as the primary authenticator of identities and then use OIDC to pass that authentication to other apps. This way users only need to sign in once with one username and password to access multiple apps. From: What Is OpenID Connect (OIDC)? | Microsoft Security

OIDC GitHub flow process (Standard) The following diagram gives an overview of how GitHub's OIDC provider integrates with your workflows and cloud provider:

1. In your cloud provider, create an OIDC trust between your cloud role and your GitHub workflow(s) that need access to the cloud.
2. Every time your job runs, GitHub's OIDC Provider auto-generates an OIDC token. This token contains multiple claims to establish a security-hardened and verifiable identity about the specific workflow that is trying to authenticate.
3. You could include a step or action in your job to request this token from GitHub's OIDC provider, and present it to the cloud provider.
4. Once the cloud provider successfully validates the claims presented in the token, it then provides a short-lived cloud access token that is available only for the duration of the job.

OIDC Power Platform Provider Flow, additional steps

In the Power Platform Terraform Provider we use OIDC Flow Client Credentials, this flow provides access to web APIs by using the identity of the application itself. It’s typically used for server-to-server communication and automated scripts requiring no user interaction. In addition to the standard GitHub OICD flow process: About security hardening with OpenID Connect - GitHub Docs we add two steps to authenticate with the API-s and the platform will validate the token, steps described below:

5. With the token obtained in step 4 the GitHub action running the Terraform Power platform Provider will authenticate with the power platform endpoints.
6. Power platform endpoints will validate the token and relay on the OIDC setup permissions and roles to interact with the Power Platform API’s to query, create, import or delete resources. The following diagram addresses all the steps required for a GitHub Action using the Power Platform Terraform Provider to authenticate and interact with Power Platform API’s.

OAUTH/OICD flow with Power Platform API’s

Additional OIDC and Power Platform Terraform Provider documentation

• The process to configure the application on Microsoft Entra its described in: Create a trust relationship between an app and an external identity provider - Microsoft Entra Workload ID | Microsoft Learn • For the application to be able to authenticate with the Power Platform API’s we document the process in the provider documentation: Creating an App Registration to use the Power Platform Provider - Power Platform Terraform Provider (pages.github.io) • We also document how to “Authenticating to Power Platform using a Service Principal with OIDC” • We have Quick Start guide to create a OIDC GitHub Actions pipeline: power-platform-terraform-quickstarts/quickstarts/102-github-pipeline at main · microsoft/power-platform-terraform-quickstarts • OIDC Implementation in the repo: terraform-provider-power-platform/internal/powerplatform/api/auth.go at main · microsoft/terraform-provider-power-platform (github.com)

[ExpressDead]

As discussed with @eduardodfmex, the OIDC/OAUTH Client Credentials Flow should be a fallback. As a rule of thumb Managed Identities should be used wherever possible. This may not currently be possible with the GitHub scenario. It would be wise to confirm the lack of support for MI in this workflow, document that result alongside the decision for OIDC, and plan to move to MI when it is possible.

[eduardodfmex]

@ExpressDead and Yogi thank you for your review, as we discussed, I create this Issue to track the MI for the provider and explore if in the future can be used with GitHub Actions: https://github.com/microsoft/terraform-provider-power-platform/issues/243.

[yogitasrivastava]

approved the security review based on agreement that managed identity will be considered for this tf provider as and when it is supported for github actions in the future.