0

I am deploying a container in AKS cluster.

I want to mount a configuration folder ( size 200+ MB ) into this container. The configuration folder is present in a git repo. Each customer has his own configuration data and is stored in a separate branch in same repo.

I am thinking of below options to load the configuration folder into the container:

  1. Persistent volume claims - PVC I will create a file share and copy the config folder into it. Mount the file share into container using PVC. In this approach I need to add the storage access key/sas token to kubernetes secrets.
  2. Zip the config folder and copy it to a Blob storage. In container startup script download the zio from blob storage and mount to desired location. In this approach I have to use a SAS token to access the storage account. (This token will be saved as secret in kubernetes)
  3. In container startup script, git clone the repo containing the config folder, download it and copy to desired location. In this approach I need to use PAT token to clone the git.
  4. Copy the config folder into the docker image itself. In this approach I dont have to worry how to load the config folder in container. However since the configuration folder is customer specific and there are 100+ customers, this results in around 100+ image tags. (We have added tags for customer)

Can you please guide me which is the best option? Is there any other better approach.

I have read that there are security issues in using PVC shared volumes which could grant root permissions on node to an attacker. And also there are security concerns in using git inside a container. Can you provide more info on why/how are these security concerns?

4c74356b41
  • 69,186
  • 6
  • 100
  • 141
Sachin
  • 127
  • 9
  • Why not create a ConfigMap specific to a customer, then [volume mount the ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap)? – Chin Huang May 14 '19 at 18:49

5 Answers5

2

use init container to load the configuration folder from git repo into a shared volume between init container and main container

P Ekambaram
  • 15,499
  • 7
  • 34
  • 59
1

I would suggest using some kind of Storage and then using an NFS drive of some kind.

There is a few considerations you have to take into account: - how many writes are there - how many reads - what are the typically file size

I would advise against using the startup script to download it, as that will make your container much slower to bring up, in general, the container should be ready to serve traffic when you start it. You can do something like this on Azure https://learn.microsoft.com/en-us/azure/storage/blobs/storage-how-to-mount-container-linux

Kevin Simper
  • 1,669
  • 19
  • 32
  • 1
    I agree with @kevin Simper that we should avoid running a startup script. The container should start quickly. The approach with PVC sounds good to me. – Nilesh Gule May 19 '19 at 10:56
1

if you are using AKS you can use Azure File persistent volume claim to create the configuration, you can use file share in read-only more, that would give better security.

In my mind all the other options are a lot less convenient (and arguably less secure)

4c74356b41
  • 69,186
  • 6
  • 100
  • 141
0

I think we can do it simple way. you can use helm with hookScript my idea is

  1. when you deployment with empty PVC with quota specify
  2. then apply URL of through Configmap or environment variable or Helm variable
  3. after that when hook just use git clone from you FILE_DOWNLOAD_GIT_REPO to your PVC mount. that it :)

rid unnecessary step and can reusable. right ? :) Sorry i'm so sleepy can't write sample helm for you. But hope you get an idea. :)

udomsak chundang
  • 21
  • 4
0

I would use a git sync image (there are quite many out there). This way you should use read-only access (PAT token you mentioned should not provide write access to the repo). It has support for reading from different branches, just need to pass the value to it (easily through a helm chart). And the good thing is that you can further sync the configuration (if your microservice supports it).

I see all the other solutions more complicated.

Liviu Costea
  • 3,624
  • 14
  • 17