-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
feat: create cli commands for ApplicationSet #9584
feat: create cli commands for ApplicationSet #9584
Conversation
Codecov Report
@@ Coverage Diff @@
## master #9584 +/- ##
==========================================
- Coverage 45.69% 45.31% -0.39%
==========================================
Files 234 236 +2
Lines 28508 28827 +319
==========================================
+ Hits 13027 13063 +36
- Misses 13694 13973 +279
- Partials 1787 1791 +4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think the big question we have to answer is: should we require all write-type ApplicationSet API requests to have an un-templated spec.template.spec.project
field, or can we accept templated Project fields?
I think when @leoluz and @ishitasequeira and @jgwest and I discussed it last, we had settled on disallowing write-type API requests when the AppSet Project field was templated. But I think we can eliminate that requirement.
My proposal:
- Before each RBAC check, run
fasttemplate
over the Project field and replace each template with an asterisk. - Perform the RBAC check for the now-templated project fields.
For example, suppose I have RBAC like this:
p, appset-dev-maintainers, applicationsets, update, *-dev/*, allow
If a user tries to update an AppSet like this:
metadata:
name: apis-appset
spec:
template:
spec:
project: "{{path[0]}}-dev"
Then the following RBAC check would happen:
*-dev/apis-appset # passes because it matches the first rule
I don't think this would be too much additional code, and I think it would make the API support for ApplicationSets much more powerful. Thoughts?
After chatting with Leo... ignore my last comment, I think that can be introduced in a later PR. For now, let's just reject AppSet API requests where the project field is templated. |
The other comment I had was that maybe we should just skip the Application RBAC checks and instead document very thoroughly that granting write capabilities on applicationsets grants the ability to do a bunch of things with applications by proxy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ran into a few issues while testing the CLI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First round of code review, just looking at the code. I have not checked this out and tested locally.
cmd/util/applicationset.go
Outdated
} | ||
|
||
func readAppset(yml []byte, appsets *[]*argoprojiov1alpha1.ApplicationSet) error { | ||
yamls, _ := kube.SplitYAMLToString(yml) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if the second return value is of type error
, but if it is, is there any reason we ignore it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I was checking if the yaml has been sent or not and sending an error before it reaches here would suffice the check. But I guess after re-evaluating I feel return an error makes sense. I will update this.
project, err := s.validateAppSet(ctx, appset) | ||
if err != nil { | ||
return nil, fmt.Errorf("error validating ApplicationSets: %w", err) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be slightly modified, because in it's current form, it would allow enumeration of AppProjects without proper permissions.
In s.validateAppSet()
, it is tried to retrieve the AppProject from the K8s API referenced in the ApplicationSet resource. If this is not found, it will be returned to the caller without having checked proper privileges before.
I think it would make sense to:
- Refactor
validateAppSet
to return the project name instead of the project - Perform the permissions check using this string, instead of the
AppProject
resource - After this has been validated, get the
AppProject
from the API in this function
util/appset/appset.go
Outdated
return fmt.Sprintf("%s/%s", appSet.Spec.Template.Spec.GetProject(), appSet.ObjectMeta.Name) | ||
} | ||
|
||
func RunCommand(command v1alpha1.Command) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this used for? And where?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was using this for my prior approach. I missed removing this part of the code. Will remove it, thanks.
util/argo/argo.go
Outdated
@@ -90,6 +109,21 @@ func FilterByName(apps []argoappv1.Application, name string) ([]argoappv1.Applic | |||
return items, status.Errorf(codes.NotFound, "application '%s' not found", name) | |||
} | |||
|
|||
// FilterAppSetsByName returns an applicationset | |||
func FilterAppSetsByName(appsets []argoappv1.ApplicationSet, name string) ([]argoappv1.ApplicationSet, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this function, I'm wondering why it returns a slice, when there can be either one or none results?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am using the same object newItems everywhere. First in FilterAppSetsByName
and then for FilterAppSetsByProjects
. FilterAppSetsByName
would give one, but if q.name is empty, it would not enter that condition and directly move to FilterAppSetsByProjects
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, using a list here is convenient... but I think the List method shouldn't even accept a name "filter" (since the user should probably just use the Get endpoint).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're introducing a new resource, we should add a note to the 2.4->2.5 upgrade notes warning people that the meaning of *
in the resource column of their RBAC CSV is being expanded. The note can follow the model of the one for the new exec
resource in 2.4: https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/upgrading/2.3-2.4.md#configure-rbac-to-account-for-new-exec-resource
Conditions are pretty verbose for applicationsets. I wonder if we should trim down what we report in the wide format.
|
The
|
@ishitasequeira I opened a PR with some of the small issues I noticed while testing today. Overall, things are looking very good. Main thing is adding k8s RBAC so the server deployment can manage appsets on behalf of the user. https://github.com/ishitasequeira/argo-cd/pull/3 |
I agree. I think we should add true/false fields as well here. I will add them. |
I was wondering if we could show only conditions having |
Thanks @crenshaw-dev for the PR. I will go through it and merge the changes. |
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: CI <michael@crenshaw.dev> Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: CI <michael@crenshaw.dev> Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
Signed-off-by: ishitasequeira <ishiseq29@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks @ishitasequeira for putting so much work into this!
@jannfis do you want to give it another pass before merging?
@ishitasequeira thank you for this. do you know when this pr will be merged? would love to give this a spin :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks @ishitasequeira!
And thanks @crenshaw-dev for giving me opportunity to look over it again!
* feat: add applicationset cli commands Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * squashed commits and rebased with master Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * addressed comments Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * fix lint errors Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * Retrigger CI pipeline Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * Retrigger CI pipeline Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * feat: add applicationset cli commands Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * addressed comments Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * fix lint errors Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * Retrigger CI pipeline Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * Retrigger CI pipeline Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * Addressed PR comments Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * removed duplicate imports Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * fix CI errors Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * address PR comments Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * add k8s RBAC, docs tweaks Signed-off-by: CI <michael@crenshaw.dev> Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * rebase master branch Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * Addressed PR coments Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * remove unnecessary fields, add docs Signed-off-by: CI <michael@crenshaw.dev> Signed-off-by: ishitasequeira <ishiseq29@gmail.com> * fix unit test Signed-off-by: ishitasequeira <ishiseq29@gmail.com> Signed-off-by: ishitasequeira <ishiseq29@gmail.com> Signed-off-by: CI <michael@crenshaw.dev> Co-authored-by: CI <michael@crenshaw.dev>
Note on DCO:
If the DCO action in the integration test fails, one or more of your commits are not signed off. Please click on the Details link next to the DCO action for instructions on how to resolve this.
Checklist: