Helm warning due to config permissions

I just got my Octopus able to run a Helm Chart (Yay!) But Helm is complaining that the Kubernetes configuration file is not as secure as it should be. Here are the warnings:

April 27th 2021 00:03:39 Error
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /etc/octopus/Work/20210427060338-122311-17/staging/kubectl-octo.yml
April 27th 2021 00:03:39 Error
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /etc/octopus/Work/20210427060338-122311-17/staging/kubectl-octo.yml

From what I read here, this was a change in version 3.3.3 of Helm (back in September) based on a Security Audit by the CNCF. They seem fairly adamant that they will not offer a way to suppress it.

Since this file come from the /etc/octopus/Work folder, I am guessing it is created by Octopus Deploy when my Deployment Target uses the token account I setup for it.

Is there a way I can get this file setup with the right permissions so that it will not give a warning when I run a Helm chart?

Hi @OctopusSchaff

Sorry to see that you’ve run into this issue. It’s something that we’re aware of and are working towards a fix.

There was user with the same issue recently, and we discovered the workaround for now is to add chmod 600 to kubectl-octo.yml

Regards,

Where do I add the chmod call? The file seems to be made automatically by Octopus for the deployment target (I think).

Is there an event I can attach to to run the script? A “OnAuthenticated” or “OnKubeConfigCreated” event that I can put a script step on?

You should be able to run chmod 600 kubectl-octo.yml as a pre-deployment script.

You can do this by clicking on ‘Configure Features’ and enabling ‘Custom Deployment Scripts’

Could you try the above and let me know if this works for you, please?

That worked. Thank you for showing me how to do that!

But this is going to be a hassle to put in all our projects, and if it takes a while, it will be some serious clean up once it is fixed.

Is there an estimate on when Octopus will have a fix for this issue?

Do you know if there is an ETA on the fix for this issue? (It is a pain to keep in all the deployment steps.)

Hi @OctopusSchaff,

Thanks for keeping in touch! I’ll jump in here quickly since Stuart’s currently offline as part of our UK team. :slight_smile:

Unfortunately we don’t have an ETA, though this has been raised as a bug so you can track the progress of it at the following link.

Don’t hesitate to reach out with any questions or concerns going forward!

Best regards,

Kenny