Incomplete Impersonalization: End user access depends on his rights to physical storage
OSDU offers a robust RBAC based Authentication and Authorization model provided by the Entitlements service. Entitlements allows to assign the User with a limited set of roles, sufficient for the precise definition of his powers within the system. Having an ACL mechanism at the Record level ensures that these permissions are accurately projected onto the data. And with the activated connection with the Policy Service and correctly configured policies, the verification of rights becomes even more sophisticated.
It is obvious that any duplication of this mechanism is as redundant as it is harmful.
However, this duplication is currently identified at the level of additional verification of the rights of the end user account to buckets and objects of the Blob storage. First of all, this is relevant for the GCP CSP, where such behavior is found, at least, in the code of the Storage service. There are the following flaws here:
-
Impersonalization (using a service account instead of an end user account) is not always used when accessing buckets and objects of the Blob storage and depends on the "isEnableImpersonalization" boolean, which is "false" by default. This means that impersonalization is not performed and GCS requests are made on behalf of the end user account.
The logic behind preserving and maintaining this functionality is not entirely clear. After all, this contradicts the very principle of microservice architecture, implying the encapsulation of procedures for working with data within a microservice. The end user account has nothing to do with the physical storage access capabilities of the microservice itself, which must be unconditionally provided to the microservice's service account . -
The problem persists even when the "isEnableImpersonalization" boolean is set to "true" (although this boolean is not raised to "true" anywhere in our test and production environments). In this case, requests to GCS are made on behalf of a service account (datafier or another dedicated), which removes the problem of service access to data...
But! Integration tests related to checking user authorization for data manipulation are starting to fail. This happens because the hasAccess(...) method is incorrectly implemented in the code of the GoogleCloudStorage repository, and it delegates some of the checks to the GCS level, but does not perform the necessary checks at the ACL level. This leads to the fact that in the tests that check the lack of access of the test "no-data-access-tester" user to manipulate data, his false authorization occurs.
We should get rid of this by carrying out the following refactoring based on the tasks:
-
For developers:
-
refuse to use the "isEnableImpersonalization" boolean and destroy the very mention of it in the program code, thereby making impersonalization the only available mode, since all requests to data will come only from the service account under which the service is running:
- GoogleCloudStorage.class (and new ObmStorage.class) - multiple places;
- GoogleCloudStorageTest.class - one place;
- provider/storage-gcp/application.properties - "osdu.gcp.storage.gcs.enable-impersonalization" property definition
-
insert an Entitlements+ACL check of end-user rights to operations with Records in those places of the program code where it was unfairly omitted (in the hope of reliable verification of the end-user rights to physical storage). Correct validations are easily added using the methods of the DataAuthorizationService class (validateOwnerAccess, validateViewerOrOwnerAccess, hasAccess) and/or using the private method GoogleCloudStorage#validateMetadata(), which are already used for this purpose, but not everywhere.
At a minimum, checks need to be added in the methods:- GoogleCloudStorage # read (RecordMetadata record, Long version, boolean checkDataInconsistency);
- GoogleCloudStorage # hasAccess (RecordMetadata ... records)
-
-
DevOps:
- stop the practice of giving end-user accounts any rights to physical storage.
- check the configurations of the business user accounts in the IAM and revoke all privileges to cloud resources.
- stop the practice of giving end-user accounts any rights to physical storage.