When using kubernetes, authorization issue is a boring thing since we usually not care about the authorization part, we just want the feature work, like HPA.
So for this, I strongly recommend you to enable audit chain to let you know which user is on 403 in the cluster, since kubernetes often use some broker user to do the final operation instead of the user you think it should be.
To enable audit chain, refer to audit configuration.
After you enable audit, you can check the audit log via tail -f when you debug the permission denied issue. You will see something like this in audit log:
2017-03-21T03:57:09.106841886-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" ip="127.0.0.1" method="GET" user="admin" groups="\"system:masters\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
2017-03-21T03:57:09.108403639-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" response="200"
You can find the 403 ones, and try to grant (kubectl create clusterrolebinding bindname --cluster-role=role_name --user=user_name [--group=group_name]) the users or groups with proper role or cluster role (kubectl get cluster role) in proper scope.
Anyway, you have to be familiar with kubernetes, and a little knowledge about kubernetes RBAC, or you will still no idea what I am talking about.
Thanks.
Top comments (0)