I'm trying to follow this tutorial to setup an nginx-ingress controller.
It seems it was written before RBAC was fully integrated into k8s. When I get to the final step of running the nginx-controller.yaml I get back an authorization error:
no service with name default/default-http-backend found: services "default-http-backend" is forbidden: User "system:serviceaccount:default:default" cannot get services in the namespace "default"
What do I need to do to make this work with RBAC?
That hackernoon post (like most of them) is incorrent. Specifically there are no RBAC objects and the deployment is not assigned a service account (i.e.: serviceAccountName: ).
To ensure that you have the right (or enough) RBAC objects created check out the RBAC-* objects at https://github.com/mateothegreat/k8-byexamples-ingress-controller/tree/master/manifests.
Related
I am trying to see which kubernetes user is creating the deployment and what type of authentication is used (basic auth, token, etc).
I try to do it using this:
kubectl describe deployment/my-workermole
but I am not finding that type of information in there.
Cluster is not managed by me and I am not able to find it in the deployment Jenkinsfile. Where and how can I find that type of information in my kubernetes deployment but after deployment?
I cannot for the life of me find a detailed table of what all the Kubernetes RBAC verbs do. The only resource I see people recommending is this one, which is woefully inadequate.
So I've been working it out by experimentation.
Most are fairly straightforward so far, except for UPDATE. This does not seem to be able to do anything I would expect it to.
Permissions I gave my alias:
[GET, UPDATE] on [deployments] in default namespace.
Things I've tried:
kubectl set image deployment/hello-node echoserver=digitalocean/flask-helloworld --as user
kubectl edit deploy hello-node --as user
kubectl apply -f hello-node.yaml --as eks-user
These all failed with error: deployments.apps "hello-node" is forbidden: User "user" cannot patch resource "deployments" in API group "apps" in the namespace "default"
I then tried some rollout commands like:
k rollout undo deploy hello-node --as user
But they failed because I didn't have replica-set access.
TLDR: What is the point of the Kubernetes RBAC update verb?
For that matter, does anyone have a more detailed list of all RBAC verbs?
Following up this, I went to the Kubernetes REST API documentation, which has a long list of all the HTTP API calls you can make to the REST server.
I thought this would help because the one (1) table available describing what the different verbs can do did so by comparing them to HTTP verbs. So the plan was:
See what HTTP verb the update permission is equated to.
Go to the reference and find an example of using that HTTP verb on a deployment.
Test the kubectl equivalent.
So.
What HTTP verb equals the update permission?
PUT.
Example of using PUT for deployments?
Replace Scale: replace scale of the specified Deployment
HTTP Request
PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}/scale
What's the equivalent kubectl command?
Well we're scaling a deployment, so I'm going to say:
kubectl scale deployment hello-node --replicas=2
Can I run this command?
I extended my permissions to deployment/scale first, and then ran it.
Error from server (Forbidden): deployments.apps "hello-node" is forbidden: User "user" cannot patch resource "deployments/scale" in API group "apps" in the namespace "default"
Well. That also needs patch permissions, it would appear.
Despite the fact that the HTTP verb used is PUT according to the API docs, and PUT is equivalent to update according to the one (1) source of any information on these RBAC verbs.
Anyway.
My Conclusion: It appears that update is indeed pretty useless, at least for Deployments.
The RBAC setup seemed promising at first, but honestly it's starting to lose its lustre as I discover more and more edge cases and undocumented mysteries. Access permissions seem like the absolute worst thing to be vague about, or your security ends up being more through obscurity than certainty.
You can get a dump of the "allowed/supported" verbs using this krew plugin rbac-tool
# Generate a ClusterRole with all the available permissions for core and apps api groups
$ kubectl rbac-tool show --for-groups=,apps
While it won't tell you exactly the semantics of each verb - it will give yu a sense about the RBAC permissions universe your cluster have.
How to prevent a user to spawn pods in namespace with serviceaccounts that have high privileges but allow them to create namespace ?
For example, I have a cluster with velero in a velero namespace. I want to prevent the user to create pods with the veleroe serviceaccount to prevent the user to create privileged accounts. But I want that the user can create namespace and use serviceaccount with restritected PSP.
In my opinion the idiomatic way of enforcing this in Kubernetes is by creating a dynamic validating admission controller.
https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook
I know it could sound a bit complex, but trust me, it's really simple. Eventually, an admission control is simply a webhook endpoint (a piece of code) which can change and/or enforce a certain state on created objects.
So in your case: create a dynamic validating webhook and simply disallow creation of pods that does not match your restrictions, with a corresponding relevant error message.
First of all the service account used by Valero is in the Valero namespace. So if the user don't have RBAC to do anything in Valero namespace it will not be able to use the service account used by Valero. You should define RBAC for users such a way that they only can do CRUD on resources in the intended namespaces and can not do CRUD on resources in other namespaces. When I say resources it also includes service account.
I'm trying to use Pulumi to create a Deployment with a linked Service in a Kubesail cluster. The Deployment is created fine but when Pulumi tries to create the Service an error is returned:
kubernetes:core:Service (service):
error: Plan apply failed: resource service was not successfully created by the Kubernetes API server : Could not create watcher for Endpoint objects associated with Service "service": unknown
The Service is correctly created in Kubesail and the error seems to be glaringly obvious that it can't do Pulumi's neat monitoring but the unknown error isn't so neat!
What might be being denied on the Kubernetes cluster such that Pulumi can't do the monitoring that would be different between a Deployment and a Service? Is there a way to skip the watching that I missed in the docs to get me past this?
I dug a little into the Pulumi source code and found the resource kinds it uses to track and used kubectl auth can-i and low and behold watching an endpoint is currently denied but watching replicaSets and the service themselves is not.
I'm trying to run a deployment on a Kubernetes cluster at work through a GitLab CI/CD process (i.e. I don't control most of the configs). I'm also new to Kubernetes, so please forgive me if this is basic and obvious.
I have created my rolebindings:
kubectl create rolebinding [foo] --clusterrole=edit --serviceaccount=[bar]:default
And added my tokens and all settings to GitLab
When the deployment kicks off however, it will always fail at deployment with:
Error from server (Forbidden): error when creating "/builds/bar/baz/deployment.yml": service is forbidden: User "system:serviceaccount:bar:bar-service-account" cannot create services in namespace "bar"
I thought I should be working in system:serviceaccount:bar:default. why is :default being replaced with :bar-service-account and/or how do I fix this.
Many many thanks in advance
You are granting permissions to the default service account with the rolebinding you are creating. However, the deployment is not using that service account. If you look at the deployment manifest, it will have a serviceAccountName of bar-service-account.
Either change the deployment to use the default service account or change the rolebinding to grant permissions to the service account being used.