The request failed with unexpected status code 'Forbidden' when connecting to AKS (dev spaces) about dotnet-kube-client HOT 15 CLOSED

(so you don't need to use the client directly, just put the try/catch in your Main method)

from dotnet-kube-client.

Hmm, I haven't tried AKS in a while, so I can't remember the security model in use - what service account does the pod run as? And does that service account need to be granted permission to read secrets in the target namespace?

from dotnet-kube-client.

Which namespace does the pod live in, BTW? I thought the idea with dev spaces was to use different namespaces in the same cluster, in which case you may have better luck dropping the secret into the same namespace as the pod (or granting broader permissions to the pod service account).

from dotnet-kube-client.

Pod is in the Default namespace. The secret is in the same namespace

from dotnet-kube-client.

Have you checked what permissions the pod service account has?

from dotnet-kube-client.

(I think kubectl get clusterrolebindings will show you the info you need, although it's a been a while since I've worked with K8s RBAC, so I could be wrong)

from dotnet-kube-client.

ah ok - thanks. I tried that and received a long list of permissions. Not sure what I'm looking for.

NAME AGE
addon-http-application-routing-nginx-ingress-clusterrole-binding 10h
addon-http-application-routing-viewer 10h
azds:tiller-deploy 10h
cluster-admin 10h
heapster 10h
kubernetes-dashboard 8h
metrics-server:system:auth-delegator 10h
system:aws-cloud-provider 10h
system:basic-user 10h
system:controller:attachdetach-controller 10h
system:controller:certificate-controller 10h
system:controller:clusterrole-aggregation-controller 10h
system:controller:cronjob-controller 10h
system:controller:daemon-set-controller 10h
system:controller:deployment-controller 10h
system:controller:disruption-controller 10h
system:controller:endpoint-controller 10h
system:controller:expand-controller 10h
system:controller:generic-garbage-collector 10h
system:controller:horizontal-pod-autoscaler 10h
system:controller:job-controller 10h
system:controller:namespace-controller 10h
system:controller:node-controller 10h
system:controller:persistent-volume-binder 10h
system:controller:pod-garbage-collector 10h
system:controller:pv-protection-controller 10h
system:controller:pvc-protection-controller 10h
system:controller:replicaset-controller 10h
system:controller:replication-controller 10h
system:controller:resourcequota-controller 10h
system:controller:route-controller 10h
system:controller:service-account-controller 10h
system:controller:service-controller 10h
system:controller:statefulset-controller 10h
system:controller:ttl-controller 10h
system:discovery 10h
system:kube-controller-manager 10h
system:kube-dns 10h
system:kube-proxy 10h
system:kube-scheduler 10h
system:metrics-server 10h
system:node 10h
system:node-proxier 10h
system:volume-scheduler 10h

from dotnet-kube-client.

The other thing you can try is to explicitly try to retrieve the secret using KubeApiClient; somewhere inside the exception tree, there will be an HttpRequestException<StatusV1>, and you can examine its properties to get more information about the response from the K8s API.

from dotnet-kube-client.

Yeah, sorry, I don't actually have a K8s cluster at the moment, so I can't really try this stuff out myself :-(

Maybe try the suggestion above and look at the exact error message from the K8s API which should tell you what was forbidden and why?

from dotnet-kube-client.

cool will do. thanks.

from dotnet-kube-client.

In fact, if you put a try/catch block at the top level, and catch HttpRequestException<StatusV1>, you can look at the Response property on the exception - StatusV1 is the generic response returned by the K8s API and has several fields that may be useful.

from dotnet-kube-client.

Finally, i got it to re-run on my dev space. I had problems with the dev space. Some some reason it stopped running my code and I had to rebuild it. Anyway, here's the error:

I think you are right.

secrets "DBConnectionString" is forbidden: User "system:serviceaccount:default:default" cannot get secrets in the namespace "default"

from dotnet-kube-client.

I just want to make sure I'm querying for the right thing:

Should I be querying for secret name (as shown it ends in appsettings), as shown?

I'm querying for DBConnectionString at the moment.

Hope I'm not making a very basic error myself.

Here;s the call I am making:

return configuration.AddKubeSecret(secretName: DbConnectionString, clientOptions: KubeClientOptions.FromPodServiceAccount(), kubeNamespace: "default", reloadOnChange: true

where DbConnectionString = "DBConnectionString"

from dotnet-kube-client.

Ah, no - secretName refers to the name of the SecretV1 resource (e.g. xxxxx-appsettings in the screenshot above), not a key inside it. The keys inside it become keys in the IConfiguration (that can then be bound to options). So you can either retrieve the connection string in your app using:

string connectionString = Configuration["DBConnectionString"];

Or bind it to options using:

class MyOptions
{
    public string DBConnectionString { get; set; }
}

services.Configure<MyOptions>(Configuration);

Looking at the above API usage, I'm wondering whether I should allow for a prefix for the configuration generated by AddKubeSecret.

from dotnet-kube-client.

thanks for this. I think as you describe the issue is permissions related and I was making the call anyway by trying to use the wrong secret name.

from dotnet-kube-client.