potiuk commented on a change in pull request #8974:
URL: https://github.com/apache/airflow/pull/8974#discussion_r434771317
##########
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:
Actually that was misleading in the original implementation. I checked
the paths and it was not working correctly. If you look at the past
implementation mount_point was not passed to the auth methods:
For example:
```
_client.auth_kubernetes(role=self.kubernetes_role, jwt=jwt)
```
when you look inside, mount_point defaults to "kubernetes". So no matter
what you specified as mount_point, always "kubernetes" was used. There was
actually no way to authenticate with the selected mount point in the earlier
version - you only retrieve the secret with the mount_point but authentication
was always done with the default "kubernetes" one.
But you are right that this might need an UPDATING entry. I actually start
thinking that maybe it is too much of a change (though I believe that this is
desired behaviour to keep same mount_point in both "auth" and "get_secret" case)
WDYT?
----------------------------------------------------------------
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]
