-
Notifications
You must be signed in to change notification settings - Fork 3.2k
-
Hi all, I've been trying to get any kind of API access using a service account token on my local k3d cluster. I installed v3.5.8 of argo workflows and My goal was to access the following API endpoint: I've set up the service account using the following script: kubectl create namespace dev
kubectl create sa -n dev tb
kubectl apply -n dev -f argo-role.yaml
kubectl create rolebinding argo --serviceaccount dev:tb --role argo
kubectl apply -n dev -f token.yaml
kubectl get secret -n dev tb.service-account-token -o=jsonpath='{.data.token}' | base64 --decode argo-role.yaml apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: argo
rules:
# k8s standard APIs
- apiGroups:
- ""
resources:
- events
- pods
- pods/log
verbs:
- get
- list
- watch
# Argo APIs. See also https://github.com/argoproj/argo-workflows/blob/main/manifests/cluster-install/workflow-controller-rbac/workflow-aggregate-roles.yaml#L4
- apiGroups:
- argoproj.io
resources:
- eventsources
- sensors
- workflows
- workfloweventbindings
- workflowtemplates
- clusterworkflowtemplates
- cronworkflows
- cronworkflows
- workflowtaskresults
verbs:
- get
- list
- watch role-binding.yaml apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: transformation-builder
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: argo
subjects:
- kind: ServiceAccount
name: tb
namespace: dev token.yaml apiVersion: v1
kind: Secret
metadata:
name: tb.service-account-token
annotations:
kubernetes.io/service-account.name: tb
type: kubernetes.io/service-account-token Then when I try to access the aforementioned endpoint using the token obtained by the script I get the following response:
This response was not helpful at all, however after downgrading argo workflows to v3.5.4 and sending the same request I got the following response
This lead me to change the role the following (Only changing metadata.name to apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: dev:argo
rules:
# k8s standard APIs
- apiGroups:
- ""
resources:
- events
- pods
- pods/log
verbs:
- get
- list
- watch
# Argo APIs. See also https://github.com/argoproj/argo-workflows/blob/main/manifests/cluster-install/workflow-controller-rbac/workflow-aggregate-roles.yaml#L4
- apiGroups:
- argoproj.io
resources:
- eventsources
- sensors
- workflows
- workfloweventbindings
- workflowtemplates
- clusterworkflowtemplates
- cronworkflows
- cronworkflows
- workflowtaskresults
verbs:
- get
- list
- watch kubectl create namespace dev
kubectl create sa -n dev tb
kubectl apply -n dev -f argo-role.yaml
kubectl create rolebinding argo --serviceaccount dev:tb --role dev:argo
kubectl apply -n dev -f token.yaml
kubectl get secret -n dev tb.service-account-token -o=jsonpath='{.data.token}' | base64 --decode I wanted to report this because this has been an extremely painful experience that cost me a lot of time. I still do not understand why I had to prepend my role's name with I think the examples in the docs should be improved. Given that I am a new user of this project I do not know whether the error message I got on v3.5.8 is intended, but the error message I got in v3.5.4 was much clearer and actually led to me solving my issue. |
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment · 5 replies
-
Your shell command and the created That's not an Argo error, and these aren't really Argo specific, it's mainly plain k8s. The Argo API is largely just an intermediary to k8s and uses the same permissions your existing k8s SAs have. See also the
The Quick Start does not reference the API and does not have manual Role or RoleBinding creation, as it uses the quick start manifests. So I'm not sure exactly why you were referring to it, and that seems mistaken. Entirely separate to the Quick Start, there is an "Access Token" page that does instruct on this. I'm not sure if that's what you were referring to, but the equivalent shell command to create a kubectl create rolebinding jenkins --role=jenkins --serviceaccount=argo:jenkins Note that it has The commands there also do not include a namespace -- given that you have
You did not say what kind of script or command you used to access the API. Your commands go as far as getting the SA token but not farther. |
Beta Was this translation helpful? Give feedback.
All reactions
-
You are absolutely right on your observations. It seems I made some errors working back from my working setup to what I had before that.
This was one such error. I have updated the shell script to reflect this.
Yes I meant the Access token page. I followed this one word for word and it led to the responses I posted on v3.5.8. The configuration I provided was what finally allowed me to access the API and the state of it before that. I have tried many combinations of namespaces but none seems to work.
I have used curl, postman and argo UI. |
Beta Was this translation helpful? Give feedback.
All reactions
-
Now you have two different scripts, both of which have issues in them -- the unnecessary colon and the lack of You also still have a completely unused
Given all the issues, I'm not sure you have what you tried initially, and all of the above have issues in them regardless.
Except that you quite literally did not follow it "word for word". You customized it several times, and your customizations have errors in them, such as adding a namespace but missing it in the
What is the exact Those errors are in your code and not in the docs. |
Beta Was this translation helpful? Give feedback.
All reactions
-
I did exactly what the page told me to do. I did not say what I ended up with is what the guide says. You can simply execute the steps and find it does not work. The curl call is also included in said guide. The configuration I ended up with that works is not what the guide says you should do. Is it the most optimal configuration? I wouldn't think so, but atleast it works. I do not appreciate your condescending tone. If you would like to help new users adopt your project feel free to try your own guide, but I will not be returning to this thread. |
Beta Was this translation helpful? Give feedback.
All reactions
-
👎 1
-
I'm sorry but I don't know how to interpret this: you said you followed it and got errors, then gave commands that produce the errors, but the commands are not the ones from the docs. This sounds like either option is problematic, and I instead did my best in a middle ground to reverse engineer and assume you meant a different docs page than the one you initially wrote and linked, but made mistakes in customizing the provided commands which caused your results. The best I can do is to interpret what you wrote and attempt to fill in the gaps, which is what I did.
I know it is, but I want to know what you tried in order to reproduce exactly.
You asked for help in GH Discussions, and an unpaid volunteer maintainer spent over a half hour interpreting your comments and responding to them, at length and in detail, pointing out the exact, specific flaws in them that would lead to the results you got (or that otherwise do not add up). They also linked to multiple other docs and help text that might help you understand those flaws. You then subsequently told them you did make mistakes, and made a few changes to your original comment, that the unpaid volunteer maintainer continued to show had specific flaws in them that do not match the docs and hence would produce resulting errors. That unpaid volunteer maintainer did so to help you understand the errors in your code -- they did not have to respond at all and did so using their own free time -- and you proceeded to not thank them for all their unpaid volunteer time but instead call them condescending for even trying to help you. It's worth noting that Maintainers are historically well-known as unpaid, under-staffed, under-appreciated, burnt out, and have many other mental health issues that stem directly from their work on OSS, which most do not do for any sort of gain or profit. |
Beta Was this translation helpful? Give feedback.
All reactions
-
I cannot reproduce this. Using the standard kubectl create role jenkins --verb=list,update --resource=workflows.argoproj.io
kubectl create sa jenkins
kubectl create rolebinding jenkins --role=jenkins --serviceaccount=argo:jenkins
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: jenkins.service-account-token
annotations:
kubernetes.io/service-account.name: jenkins
type: kubernetes.io/service-account-token
EOF
ARGO_TOKEN="Bearer $(kubectl get secret jenkins.service-account-token -o=jsonpath='{.data.token}' | base64 --decode)"
curl https://localhost:2746/api/v1/workflows/argo -H "Authorization: $ARGO_TOKEN" Logs out:
It's worth noting that the "Access Token" page has not changed altogether much since its inception 4 years ago in #3316. |
Beta Was this translation helpful? Give feedback.
Your shell command and the created
RoleBinding
, as quoted above, has--role dev:argo
.That's not an Argo error, and these aren't really Argo specific, it's mainly plain k8s. The Argo API is largely just an intermediary to k8s and uses the same permissions your existing k8s SAs have.
See also the
--help
message for thekubectl
command: