Token Authentication Fails, Token in Config isn't base64 encoded

[jonstelly]

I've got a microk8s cluster and by default the admin user is set up for basic username/password authentication. Since this client doesn't support username/password authentication I generated a token for authentication and changed my user entry to use the token.

I got the token by running the following PowerShell script:

$secrets = kubectl -n kube-system get secret -o=json | ConvertFrom-Json;
$admin = $secrets.items.Where( { $_.metadata.name -like 'admin-user*' });
$token = [Text.Encoding]::ASCII.GetString([Convert]::FromBase64String($admin.data.token));

If I take the value from that script, I can use the token to log into the dashboard, and placing the token in the kubernetes config file, kubectl get all works as expected but the token doesn't seem to be base64 encoded (It has non-base64 characters). If I try to use this kubernetes client, I get this exception:

System.FormatException : The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters.
   at System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
   at System.Convert.FromBase64String(String s)
   at KubeClient.Extensions.KubeConfig.Models.UserIdentityConfig.GetRawToken() in C:\code\gh\dotnet-kube-client\src\KubeClient.Extensions.KubeConfig\Models\UserIdentityConfig.cs:line 64
   at KubeClient.K8sConfig.ConfigureKubeClientOptions(KubeClientOptions kubeClientOptions, String kubeContextName, String defaultKubeNamespace) in C:\code\gh\dotnet-kube-client\src\KubeClient.Extensions.KubeConfig\K8sConfig.cs:line 200
   at KubeClient.K8sConfig.ToKubeClientOptions(String kubeContextName, String defaultKubeNamespace, ILoggerFactory loggerFactory) in C:\code\gh\dotnet-kube-client\src\KubeClient.Extensions.KubeConfig\K8sConfig.cs:line 150
   at KubeClient.Extensions.KubeConfig.Tests.K8sConfigLocationTests.ConnectToHome() in C:\code\gh\dotnet-kube-client\test\KubeClient.Extensions.KubeConfig.Tests\K8sConfigLocationTests.cs:line 81
--- End of stack trace from previous location where exception was thrown ---

So I tried to base64 encode the value. More Powershell:

[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('TOKEN_GOES_HERE')

And replaced the token value in my config file with the encoded value. When I do that, kubectl get all fails to authenticate and so does this client.

My assumption is that only http bearer strings are base64 encoded. If so, a change like the following seems like it would make sense. Does this look right? My assumption could obviously be wrong and this might break something. I tried looking through the kubectl code, but the phrases bearer and token show up a ton in the code so I wasn't able to find what I was looking for.

[tintoy]

Hi - thanks, yep looks good to me :)

[tintoy]

Build is running now.

[tintoy]

Published v2.2.11.

[tintoy]

A pity this will probably only ever be in .NET Core, and not in the full framework.

[jonstelly]

Did something change about releases? On nuget it shows that 2.2.11 was published a month ago. But on the GitHub releases page there are tags for 2.2.9 to 2.2.13 even though .12 and .13 aren’t available on nuget. I think you had mentioned switching to/from Travis in another thread, are releases still getting built and published to nuget as expected?

[tintoy]

Yes - sometimes a tagged build fails (usually due to GitVersion complaining about repo structure) and so I need to make a new tag to resolve the issue. One day I’ll get round to fixing it but since packages are being published it’s not critical :)

[tintoy]

I just haven’t had time to revisit the config for GV (sorry typing on my phone) since I upgraded it to the .NET Core version which works slightly differently because work is a little crazy. I really should though at some point. Am considering switching to Azure pipelines if I get the time because they supposedly have good integration with GV...

[jonstelly]

but since packages are being published it’s not critical :)

Maybe I'm missing something, but 2.2.11 for instance was published more than a month ago according to nuget

There was another PR I submitted 18 days ago where you said that it was published in 2.2.12 but I don't see any nuget packages for 2.2.12. I also see a 2.2.13 tag in GitHub but no 2.2.13 nuget package.

Travis looks like it failed to push due to a version conflict since 2.2.11 is already there.

This isn't urgent, just want to make sure I'm not missing something.

[tintoy]

Oh, sorry I just have misread the build log. It’s 12am here but I’ll give this a look first thing tomorrow :)

[tintoy]

Published v2.2.12.

[tintoy]

Ok I think we're good to go 🙂