-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security review #125
Comments
Adding Jayce recommendations: Here is the currently relevant links to the playbooks: Internal: https://internal.playbook.microsoft.com/ 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 |
We need to create / implement:
|
|
@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 Dependency Review I already tested the 2 actions in another repo today (simple actions with basic go code). If we agree this Issue will cover:
|
@eduardodfmex reminder to close this one out this week |
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. OIDC GitHub flow process (Standard)
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. 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 |
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. |
@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: #243. |
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. |
Security review needed for go-public. Specifically, we need:
Tasks
The text was updated successfully, but these errors were encountered: