Skip to content
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.

Sign up for GitHub

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

Jump to bottom

docs: Generic Web API Provider Configuration proposal (#18391) #18392

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

docs: Generic Web API Provider Configuration proposal (#18391) #18392

wants to merge 1 commit into from

Conversation

RedbackThomson
Copy link

@RedbackThomson RedbackThomson commented May 23, 2024 •
edited
Loading

Checklist:

  • Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
  • The title of the PR states what changed and the related issues number (used for the release note).
  • The title of the PR conforms to the Toolchain Guide
  • I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
  • I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
  • Does this PR require documentation updates?
  • I've updated documentation as required by this PR.
  • I have signed off all my commits as required by DCO
  • I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
  • My build is green (troubleshooting builds).
  • My new feature complies with the feature status guidelines.
  • I have added a brief description of why this PR is necessary and/or what this PR solves.
  • Optional. My organization is added to USERS.md.
  • Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

@RedbackThomson RedbackThomson requested review from a team as code owners May 23, 2024 18:33
@RedbackThomson RedbackThomson mentioned this pull request May 23, 2024
Open
christianh814
christianh814 approved these changes Jul 11, 2024
View reviewed changes
docs/proposals/generic-web-api-provider-config.md

Asking users to provide the parameters for an authentication request is a poor user experience. Users may not be aware of the authentication APIs for their cluster providers and therefore might not know what values are valid for their Argo CD cluster. This poor experience may be offset by documentation, provided either by Argo and/or by the cluster providers, with examples of how to configure the requests.

## Alternatives
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would using Dex's builtin AuthProxy method work/be a valuable alternative here? https://dexidp.io/docs/connectors/authproxy/

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with Dex in this context. Would this require any user to configure Dex as the authentication platform for Argo?

agaudreault
agaudreault reviewed Jul 22, 2024
View reviewed changes
docs/proposals/generic-web-api-provider-config.md

Asking users to provide the parameters for an authentication request is a poor user experience. Users may not be aware of the authentication APIs for their cluster providers and therefore might not know what values are valid for their Argo CD cluster. This poor experience may be offset by documentation, provided either by Argo and/or by the cluster providers, with examples of how to configure the requests.

## Alternatives
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe an alternative to document is a solution external to ArgoCD? A pod that lives in the argocd namespace can perform query to the cluster provider, get the token and the "interface" with Kubernetes/ArgoCD by modifying the Kubernetes secret that represent the cluster.

This solution, if it is viable and I understood the problem correctly, is not coupled to ArgoCD and is more generic since it only uses the Kubernetes API. A simple pod deployment that is configured with a CM could be hosted on argoproj-labs. It also has the advantage of not increasing the complexity in ArgoCD.

Would this work as an alternative?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I could see that working as well. There would still need to be some amount of modification to ArgoCD to support that new interface, correct?

But that also feels nicely generic sufficient to support any HTTP authentication

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@agaudreault agaudreault agaudreault left review comments

@christianh814 christianh814 christianh814 approved these changes

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
component:docs
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@RedbackThomson @christianh814 @agaudreault @crenshaw-dev