Fix unwritable .aws directory

[gurchik]

what

Mounts the AWS credentials and config secrets as individual files within a writable .aws directory, rather than mounting them in a read-only directory.

This PR has no effect if someone mounts an arbitrary AWS secret using .Values.awsSecretName because when doing that there is no way for the Chart to know the contents of the secret so it can't know which files to mount. So in this case there is no change of behavior.

why

The AWS CLI cannot work properly when the .aws directory is read-only. This is a problem since this tool is often needed in Terraform projects. For example, a common way to configure the Helm Terraform provider is to pass in an exec argument which executes the AWS CLI to get Kubernetes credentials. Without this change, that would be impossible as the AWS CLI would error.

tests

I tested my changes by deploying this to my cluster which was previously deploying version 5.18.1 of this Helm Chart.

Values:

aws:
  config: |
    redacted
  credentials: |
    redacted

Before this change:

$ kubectl exec -n atlantis atlantis-0 -- aws sts get-caller-identity

[Errno 30] Read-only file system: '/home/atlantis/.aws/cli'
command terminated with exit code 255

After this change:

$ kubectl exec -n atlantis atlantis-0 -- aws sts get-caller-identity
{
    "UserId": "redacted",
    "Account": "redacted",
    "Arn": "redacted"
}

references

closes #380
resolves dupe #421

[GMartinez-Sisti]

Hi @gurchik, thank you for the PR. I'll try to take a look at it during the weekend.

[gurchik]

@GMartinez-Sisti any update on this? :) I will bump the chart version once it's reviewed

[GMartinez-Sisti]

Blocked by helm-unittest -> helm-unittest/helm-unittest#790 (comment).

[gurchik]

@GMartinez-Sisti the checksum fails because your CI workflow hardcodes expected SHA sums that don't match what the maintainer uploaded for the helm-unittest release here. I understand that the hardcoded SHA sums used to match until the helm-unittest maintainer replaced the release artifacts. I don't know why they replaced the artifacts, but I don't think their release workflow creates reproducible builds. Therefore, I find it unlikely the maintainer will be able to get the release to match the previous checksum now that it has been changed. If you are concerned about a potential supply chain attack then feel free to continue to investigate, if not then I would recommend updating your hardcoded checksums with the new values.

[GMartinez-Sisti]

@GMartinez-Sisti the checksum fails because your CI workflow hardcodes expected SHA sums that don't match what the maintainer uploaded for the helm-unittest release here. I understand that the hardcoded SHA sums used to match until the helm-unittest maintainer replaced the release artifacts. I don't know why they replaced the artifacts, but I don't think their release workflow creates reproducible builds. Therefore, I find it unlikely the maintainer will be able to get the release to match the previous checksum now that it has been changed. If you are concerned about a potential supply chain attack then feel free to continue to investigate, if not then I would recommend updating your hardcoded checksums with the new values.

Right, we need confirmation from the maintainer that this is intended and have the checksum file updated or get a new release. This forced update goes against the best practices for released software, an artifact should never change, a new release should be published instead.

[GMartinez-Sisti]

Hi @gurchik, #524 has unblock this. Please rebase so we can check the tests.