Config Management Plugins can pull dependencies from private repositories.

Why is this important?

There isn't any mention of intentionally restricting CMP to public repos in the docs, so it’s reasonable that customers assume that private repos are accessible.

I had assumed that when creating a CMP and extending Argo CD to integrate with more tooling that I would be able to bring in dependencies from private repos. Allowing users to BYO and customise the supported integrations should open the door to in-house config management solutions that may live in private repos. 

Limiting customers to public repos only presents security challenges for some organisations.

Though this issue itself isn't a significant problem by itself, I have assigned it Major priority as it's blocking at least one customer's upgrade from OCP 3 to 4. 

Scenarios

1. Those with strict requirements who aren’t able to use third party tooling without approval build a lot more privately maintained software. Being forced to grant an exception for Argo CD to use a public version of something would be a blocker for teams getting the functionality that they need.
2. Teams must choose between using publicly available plugins (which may not suit their needs entirely) and having to make their custom plugin publicly available (which may not be possible for copyright or security reasons)

Dependencies (internal and external)

Issue reported by a customer via RFE: https://issues.redhat.com/browse/RFE-2976

And also reported upstream: https://github.com/argoproj/argo-cd/issues/10265 

Acceptance Criteria (Mandatory)

* Come up with a proposal document for introducing support for private dependencies to Sidecar CMP Plugins

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met