You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2020/02/07 05:58:00 UTC
[jira] [Commented] (AIRFLOW-4301) Secrets in KubernetesPodOperator
are not mapped as expected for deploy_type volume
[ https://issues.apache.org/jira/browse/AIRFLOW-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032123#comment-17032123 ]
ASF GitHub Bot commented on AIRFLOW-4301:
-----------------------------------------
stale[bot] commented on pull request #5922: [AIRFLOW-4301] Fix KubernetesPodOperator secret volume mapping
URL: https://github.com/apache/airflow/pull/5922
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
> Secrets in KubernetesPodOperator are not mapped as expected for deploy_type volume
> ----------------------------------------------------------------------------------
>
> Key: AIRFLOW-4301
> URL: https://issues.apache.org/jira/browse/AIRFLOW-4301
> Project: Apache Airflow
> Issue Type: Bug
> Components: operators
> Affects Versions: 1.10.2
> Reporter: Hüdaverdi Cakir
> Priority: Major
> Labels: kubernetes
>
> Consider following secret configuration:
> {code:python}
> secret1 = Secret('volume', '/usr/src/app/config/secret1.json', 'k8s-creds', 'secret-file1')
> secret2 = Secret('volume', '/usr/src/app/config/secret2.json', 'k8s-creds', 'secret-file2')
> {code}
> h2. observed
> When this configuration is deployed via the KubernetesPodOperator, following files are visible in the pod (container):
> {code:bash}
> # ls -l /usr/src/app/config/secret1.json
> total 0
> lrwxrwxrwx 1 root root 10 Apr 12 18:17 secret-file1 -> ..data/secret-file1
> lrwxrwxrwx 1 root root 15 Apr 12 18:17 secret-file2 -> ..data/secret-file2
> lrwxrwxrwx 1 root root 11 Apr 12 18:17 secret-file3 -> ..data/secret-file3
> # ls -l /usr/src/app/config/secret2.json
> total 0
> lrwxrwxrwx 1 root root 10 Apr 12 18:17 secret-file1 -> ..data/secret-file1
> lrwxrwxrwx 1 root root 15 Apr 12 18:17 secret-file2 -> ..data/secret-file2
> lrwxrwxrwx 1 root root 11 Apr 12 18:17 secret-file3 -> ..data/secret-file3
> {code}
> As you can see, all secrets were mapped per {{deploy_target}} (e.g. secret1.json), regardless what {{key}} (e.g. secret-file1) was provided. This also includes a third key (secret-file3) which was never meant to be exposed.
> h2. expected
> For {{deploy_type=volume}}, when {{key}} is provided, {{deploy_target}} should be considered as a single file, and not as a folder.
> Whereas, when {{key}} is not provided, then {{deploy_target}} should be considered as a folder and all secret keys under given secret should be mapped.
> h2. workaround
> Using {{VolumeMount}} and {{Volume}} for mapping secrets manually.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)