Client scripts
If you run a script on your own machine that connects to kubernetes (either by using kubectl or directly), you should avoid using the config file provided by the portal, since token refresh doesn't work in concurrent runs. Instead you should create a service account in your namespace and connect using the token generated by kubernetes.
All further actions can only be done by a namespace admin. If you have a user status, ask your admin to do this.
To create a service account, run:
(replace <service-account-name> with desired name)
Kubernetes will create one for you, and also generate a token in a secret object. First get the name of the secret:
TOKENNAME=`kubectl get serviceaccount/<service-account-name> -o jsonpath='{.secrets[0].name}'`
echo $TOKENNAME
Then get the secret using the TOKENNAME we found:
After that COPY your current OIDC config file, and add the new user instead of the current one.
cp .kube/config .kube/config_sa
kubectl --kubeconfig=.kube/config_sa config set-credentials <service-account-name> --token=$TOKEN
kubectl --kubeconfig=.kube/config_sa config set-context --current --user=<service-account-name>
kubectl --kubeconfig=.kube/config_sa config view
kubectl --kubeconfig=.kube/config_sa config unset users.http://cilogon.org/server<your_cilogon_user_id>
Now you need to let the service account act on behalf of user. To do this, run:
kubectl create rolebinding <service-account-name>-sa --clusterrole=<admin OR edit> --serviceaccount=<namespace>:<service-account-name>
Namespace admins have the admin role, and users typically have the edit role. https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
Now check if you can list pods:
(You can also set the environmental variable $KUBECONFIG with the location of your config file for the script)