How to manage service account token usage in K8s?

Using a service account to interact with a kubernetes cluster from outside the cluster using kubectl or CI/CD systems is not the best approach from security point of view. You should rather use a authenticating proxy wherein generation and rotation of short lived JWT token is delegated to an external OpenId/oAuth complaint authorization system.

Service accounts should only be used from a pod running inside the cluster and you can limit the authorization of the service account by RBAC Role and RoleBinding. Keep in mind that currently service account tokens are not rotated by kubernetes.

Assume a developer in company copy this token for himself (and no ones know that) and after he left the company he still have access to our Kubernetes cluster. I want to limit his access. How can I do that?

Yes, this is a risk that you have to mitigate.

In Kubernetes, you can now use tokens that are only valid for a short time, e.g. an hour. If you can, use Service Account from a projected volume. See also No more forever tokens. In fact, I think this is a better approach for most Service Account usage - from a security standpoint.

If you use a Kubernetes-native CI/CD Pipeline, e.g. by using Tekton you can deploy using these newer tokens that are rotated regularly.

If you deploy from outside the cluster, @Arghya Sadhu provided a good alternative, by using an authentication proxy.

Using Kubernetes at a cloud provider?

If you use Kubernetes at a cloud provider and deploy from a CI/CD outside of the cluster, they usually have federated identity solutions, e.g. AWS IAM roles for EKS service accounts or Google Workload Identity for GKE