potiuk commented on a change in pull request #8974:
URL: https://github.com/apache/airflow/pull/8974#discussion_r435350929
##########
File path: airflow/providers/hashicorp/secrets/vault.py
##########
@@ -58,155 +54,127 @@ class VaultBackend(BaseSecretsBackend, LoggingMixin):
:type variables_path: str
:param url: Base URL for the Vault instance being addressed.
:type url: str
- :param auth_type: Authentication Type for Vault (one of 'token', 'ldap',
'userpass', 'approle',
- 'github', 'gcp', 'kubernetes'). Default is ``token``.
+ :param auth_type: Authentication Type for Vault. Default is ``token``.
Available values are in
+
:py:const:`airflow.providers.hashicorp.common.vault_client.VALID_AUTH_TYPES`.
:type auth_type: str
- :param mount_point: The "path" the secret engine was mounted on. (Default:
``secret``)
+ :param mount_point: The "path" the secret engine was mounted on. Default
depends on the engine used.
:type mount_point: str
+ :param kv_engine_version: Select the version of the engine to run (``1``
or ``2``, default: ``2``)
+ :type kv_engine_version: int
:param token: Authentication token to include in requests sent to Vault.
(for ``token`` and ``github`` auth_type)
:type token: str
- :param kv_engine_version: Select the version of the engine to run (``1``
or ``2``, default: ``2``)
- :type kv_engine_version: int
:param username: Username for Authentication (for ``ldap`` and
``userpass`` auth_type)
:type username: str
:param password: Password for Authentication (for ``ldap`` and
``userpass`` auth_type)
:type password: str
- :param role_id: Role ID for Authentication (for ``approle`` auth_type)
+ :param key_id: Key ID for Authentication (for ``aws_iam`` and ''azure``
auth_type)
+ :type key_id: str
+ :param secret_id: Secret ID for Authentication (for ``approle``,
``aws_iam`` and ``azure`` auth_types)
+ :type secret_id: str
+ :param role_id: Role ID for Authentication (for ``approle``, ``aws_iam``
auth_types)
:type role_id: str
:param kubernetes_role: Role for Authentication (for ``kubernetes``
auth_type)
:type kubernetes_role: str
- :param kubernetes_jwt_path: Path for kubernetes jwt token (for
``kubernetes`` auth_type, deafult:
+ :param kubernetes_jwt_path: Path for kubernetes jwt token (for
``kubernetes`` auth_type, default:
``/var/run/secrets/kubernetes.io/serviceaccount/token``)
:type kubernetes_jwt_path: str
- :param secret_id: Secret ID for Authentication (for ``approle`` auth_type)
- :type secret_id: str
:param gcp_key_path: Path to GCP Credential JSON file (for ``gcp``
auth_type)
+ Mutually exclusive with gcp_keyfile_dict
:type gcp_key_path: str
+ :param gcp_keyfile_dict: Dictionary of keyfile parameters. (for ``gcp``
auth_type).
+ Mutually exclusive with gcp_key_path
+ :type gcp_keyfile_dict: dict
:param gcp_scopes: Comma-separated string containing GCP scopes (for
``gcp`` auth_type)
:type gcp_scopes: str
+ :param azure_tenant_id: Tenant of azure (for ``azure`` auth_type)
+ :type azure_tenant_id: str
+ :param azure_resource: Resource if of azure (for ``azure`` auth_type)
+ :type azure_resource: str
+ :param radius_host: Host for radius (for ``radius`` auth_type)
+ :type radius_host: str
+ :param radius_secret: Secret for radius (for ``radius`` auth_type)
+ :type radius_secret: str
+ :param radius_port: Port for radius (for ``radius`` auth_type)
+ :type radius_port: str
"""
def __init__( # pylint: disable=too-many-arguments
self,
connections_path: str = 'connections',
variables_path: str = 'variables',
url: Optional[str] = None,
auth_type: str = 'token',
- mount_point: str = 'secret',
+ mount_point: Optional[str] = None,
Review comment:
OK. I think I understood now. what you were trying to say @kaxil. So in
other words - even if authentication is done via "kubernetes" engine you still
wanted to read from "secret" engine? Which means that if we have -for example
Google Secret Backend connected we would authenticate with Google Secret one,
but then read from the secret engine that is connected at "secret" mount_point
? That sounds a bit counter-intuitive I think. Do we still want to support the
pattern that we authenticate using one engine and using another to read
secrets? that does not seem right.
Should we have separate "authentication mount_point" and "secret retrieval
mount_point" eventually? That also sounds a bit strange (though we can likely
figure some defaults for that that would make sense).
----------------------------------------------------------------
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]
