galuszkak commented on a change in pull request #4772: [AIRFLOW-3937]
KubernetesPodOperator support for envFrom configMapRef…
URL: https://github.com/apache/airflow/pull/4772#discussion_r264536940
##########
File path: airflow/contrib/kubernetes/secret.py
##########
@@ -14,28 +14,41 @@
# KIND, either express or implied. See the License for the
# specific language governing permissions and limitations
# under the License.
+from airflow.exceptions import AirflowConfigException
class Secret:
"""Defines Kubernetes Secret Volume"""
- def __init__(self, deploy_type, deploy_target, secret, key):
+ def __init__(self, deploy_type, deploy_target, secret, key=None):
"""Initialize a Kubernetes Secret Object. Used to track requested
secrets from
the user.
:param deploy_type: The type of secret deploy in Kubernetes, either
`env` or
`volume`
:type deploy_type: str
:param deploy_target: The environment variable when `deploy_type`
`env` or
- file path when `deploy_type` `volume` where expose secret
+ file path when `deploy_type` `volume` where expose secret.
+ If `key` is not provided deploy target should be None.
:type deploy_target: str
:param secret: Name of the secrets object in Kubernetes
:type secret: str
- :param key: Key of the secret within the Kubernetes Secret
+ :param key: (Optional) Key of the secret within the Kubernetes Secret
Review comment:
@dimberman that depends how people manage secrets objects.
There are 2 approaches.
A) Secret object in k8s holds all necessary secret to one service like DB.
So if You need 2 services like PostgreSQL and MySQL You mount 2 secret objects
`postgresql-secret` and `mysql-secret` and they are available in containers.
Every secret object has 3-4 keys (like user, password, port etc.)
B) Secret object per deployment object/stateful set. So all necessary secret
keys for deployment object are in one secret object. So if there are 5
microservices, there are a corresponding 5 secret objects.
Having all secrets in one secret object I would consider as really bad
practice in k8s, You should have always some practice to have secrets
segregated by some rules in different secret objects to make it more
maintainable.
In context of airflow I would assume to have secret objects like in case of
A). So I mount to env variables only this services credentials that will be
used by KubernetesPodOperator.
Mounting key by key is giving a lot of maintenance burden and is much more
error-prone for typo or other issues like that.
----------------------------------------------------------------
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:
[email protected]
With regards,
Apache Git Services
