yes, we're using this implementation. PostgreSQL is available on all CSPs:
So it would be easy to use entitlements-v2-jdbc on any CSP as well as on-prem.
@ethiraj there is the link to Entitlement V2 implementation that uses jdbc: https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/tree/master/provider/entitlements-v2-jdbc
Both of the following findings were investigated and found the false positive (and BTW both were marked as remediated in Vulnerability Report):
master
branch:
https://community.opengroup.org/osdu/platform/system/indexer-queue/-/blob/001d9a69e55f539fba82d7a7253234cdcd28d8a2/indexer-queue-ibm/src/main/resources/application.properties#L13
ibm.rabbitmq.uri=amqps://user:pwd@host.databases.appdomain.cloud:port
master
branch:
https://community.opengroup.org/osdu/platform/system/file/-/blob/227d053651df3390bfe91b9cb9edea8b7ba5aba2/provider/file-gcp-datastore/src/test/java/org/opengroup/osdu/file/provider/gcp/repository/TestCredential.java#L42
static {
PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(SecurityTestUtils.newEncodedRsaPrivateKeyBytes());
SA_PRIVATE_KEY_PKCS8 = "-----BEGIN PRIVATE KEY-----\n"
+ new String(Base64.getEncoder().encode(keySpec.getEncoded()))
+ "\n-----END PRIVATE KEY-----\n";
}
There were no 'high' severity vulnerabilities in Indexer Queue and File
My two cents:
These are risks we need to be accountable for.
Updated the file /downloadURL API to download files with the user-provided file name in the metadata payload Issue #35
I'm supporting the idea of separation security control by partiotion.
I support using handler to intercept exact event rather than filter everything.
As a former CISSP I want to remind you that audit cannot be optional and depend on the goodwill of the programmer who implements the service. Shall we use reverse proxy to capture API calls with its parameters, caller info, and entitlement decision? This common implementation of auditing facility seems sufficient. Thus we can guarantee that ALL calls will be audited and, as another benefit, we will increase common code usage.
osdu/platform/system/lib/core/os-core-common#47
Provides info about maven build and git
How did it happen that this MR was marked as just for Azure, but it also changed file-core/src/main/java/org/opengroup/osdu/file/service/FileDmsServiceImpl.java?
we can move this small piece of code to core common, but each service should:
+1
this MR looks good
osdu/platform/system/lib/core/os-core-common#47
Provides info about maven build and git
osdu/platform/system/lib/core/os-core-common#47
Provides info about maven build and git
osdu/platform/system/lib/core/os-core-common#47
Provides info about maven build and git
osdu/platform/system/lib/core/os-core-common#47
Provides info about maven build and git
Adding a checksum can easily be done at build time. It assumes that there is the only ONE artifact per service to deploy, which may require to change the build and deployment processes for some services.
Sample Storage Instructions Response will be as follows
{
"storageLocation": {
"key1": "value1",
"key2": "value2"
},
"providerKey": "AZURE"
}
Sample Retrieval Instructions response will be as follows
{
"datasets": [{
"datasetRegistryId": "value1",
"retrievalProperties": {}
},{
"datasetRegistryId": "value2",
"retrievalProperties": {}
}],
"providerKey": "AZURE"
}
Sample copy dms request
{
"datasetSources": [{
"kind": "{{partition-id}}:wks:dataset--File.Generic:1.0.0",
"acl": {
},
"legal": {
},
"data": {
"DatasetProperties": {
"FileSourceInfo": {
"FileSource": "{{fileSource}}"
}
}
}
}]
}
Sample copy dms response
[
{
"success": true,
"datasetBlobStoragePath": "<url at which the dataset is copied to>"
}
]