Kube-rs: APIClient uses system:anonymous service account when running code locally

[thavlik]

#[cfg(test)]
mod test {
    use k8s_openapi::api::apps::v1beta1::{DeploymentSpec, DeploymentStatus};
    use k8s_openapi::api::core::v1::Pod;
    use kube::{
        api::{Api, DeleteParams, Object},
        client::APIClient,
        config::{self, ConfigOptions, Configuration},
    };

    #[tokio::test]
    async fn test_general() {
        let config = config::load_kube_config_with(ConfigOptions{
            context: Some(String::from("do-nyc1-dev")),
            cluster: Some(String::from("do-nyc1-dev")),
            user: Some(String::from("do-nyc1-dev-admin")),
        }).await.unwrap();
        let client = APIClient::new(config);

        let pods: Api<Pod> = Api::namespaced(client, "default");

        let p = pods.get("blog").await.unwrap();
        println!(
            "Got blog pod with containers: {:?}",
            p.spec.unwrap().containers
        );
    }
}

KUBECONFIG=$HOME/.kube/config cargo test
---- test::test_general stdout ----
thread 'test::test_general' panicked at 'called `Result::unwrap()` on an `Err` value: Api(ErrorResponse { status: "Failure", message: "pods \"blog\" is forbidden: User \"system:anonymous\" cannot get resource \"pods\" in API group \"\" in the namespace \"default\"", reason: "Forbidden", code: 403 })', src/main.rs:75:17

For reference, here is the ExecCredentials command from my kubeconfig:

- name: <my-cluster-name>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - kubernetes
      - cluster
      - kubeconfig
      - exec-credential
      - --version=v1beta1
      - --context=default
      - <uuid>
      command: doctl
      env: null

[thavlik]

I figured it out. It appears client certificate auth is not implemented. Check out how the branch in create_client_builder returns an optional token but will discard client certificate credentials in favor of token authorization:
https://github.com/clux/kube-rs/blob/cc7ffcbb54945719afd6884b9b3aed93c569a2b4/kube/src/config/mod.rs#L109

Temporary workaround is to generate a k8s access token and create a new user in ~/.kube/config that uses the token:

users:
- name: rust
  user:
    token: <redacted>

...then initialize the client with the user:

let config = config::load_kube_config_with(ConfigOptions {
    user: Some(String::from("rust")),
    cluster: None,
    context: None,
}).await.unwrap();

[clux]

Thanks for this report. Yeah, the config module is a little neglected on these fronts because they are hard to test without all the different types of auth setups (some of which need to write to the ~/.kube/config and then we have to make a mechanism to re-read from it). On top of this there's always work arounds for them, like you found (or more generally impersonating simple service account token auth).

That said I'm definitely happy to take PRs for these if they come with some sanity unit tests. But don't really have time to really dig into this myself atm. :cry:

[thavlik]

Upon testing, I do not encounter this issue with master (was previously using 0.30.0):

[dependencies]
kube = { git = "https://github.com/clux/kube-rs.git" }
kube-derive = { git = "https://github.com/clux/kube-rs.git" }

I'm curious if the above PR would fix some functionality. Seems weird to throw away the cert given by auth_exec when the client-go library definitely caches them.