-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for COS - ActivityTracker integration and IP filtering configuration #1487
Comments
Hello there, there is an additional need regarding this. Let me know if you want me to create another ticket.
It should not be. |
We are working on this feature to attach firewall ip's activity tracker, monitoring crn...It will be part of the next release |
Great ! |
@ifs-pauljegouic Regarding this Since you added some Bucket AccessPolicies (that includes the IP Firewall) did you added your systemIP to the list of allowed IP's or your system IP fall in the range of IP address...Until you add it you can't access the buckets |
The above comments are based on our investigation we found it |
ARGH so even the properties (including IDs ?) are handled on the data plane of COS ... So we don't have any solution on this use case ?
I mean no easy solution, it implies SSH tunnel or VPN. I asked the COS team to distinguish more the "administration of the service" and the "usage of the service". |
Mmmmm @hkantare I need to make more tests. Yesterday I SWEAR, I was able to edit the access policies from the console even if I was doing this from another IP than the ones informed in "Authorized IPs" And today, I am not able. |
Oh wow. After some investigations, I think I will have to make a ticket support ... Here is my usecase: 1/ I provision a COS with a Bucket I am going to check if the second IP I have informed in step 6 has been taken into account. That would result in a security breach. |
After some investigations thanks to @kevinisninja from GCAT, we have those conclusions:
--> This leads me to the initial situation where COS has 2 endpoints, and It would be great that even if the Bucket content should not be access by an IP, it can still be managed through Terraform without getting a 403 error :) If the console can do it, I bet Terraform teams can do it better than the GUI Team ;) For now:
|
Hey @hkantare, I think this might need to be pushed internally, and might be outside the scope of the provider. The customer wants terraform to be able to refresh the state of the bucket properly, without whitelisting management infrastructure location IP AFAIK This separation of control plane and data plane is possible today in ICD databases, where adding an IP whitelist will prevent access to the databases in the instance, but terraform is still able to configure/refresh the state of the instance |
@hkantare Do you know what exactly what attributes is the terraform provider trying to get that obtains a 403 failure? Because when the bucket has an IP whitelist, when you go view it via the UI, you can still see the COS instance, as well as all the buckets that are in there. What information is the provider trying to obtain that causes it to fail, since it seems like you have all the information necessary in the UI. Even with the IP firewall applied, you can still see the buckets that exist, so it doesn't seem like the provider should be failing, even if the system IP is not IP whitelisted. |
@kevinisninja terraform provider will try to set some of the bucket information like location, crn,..so on
Here you can find the set of code which we call to get the bucket information |
I've deep dive into the network call done on the GUI Console of IBM. It seems that some information that you're mentionning are available (CRN, Location) even if my IP is not whitelisted. My COS with 2 buckets, the first one apply a IP whitelist (and I am not doing those stuff through my IP. Here is the call made from the GUI Console. Maybe something to investigate here with COS Team.
Here is the response object: {
"containers":[
{
"name":"debug-gcat-bucket1",
"creation_time":"06/05/2020 8:39:12 PM",
"is_legacy":false,
"has_activity_tracking":true,
"storage_location":"eu-de-standard",
"object_count":0,
"bytes_used":0,
"sse_kp_enabled":false,
"bucket_lifecycle_policy":"Not Present",
"bucket_protection_state":"DISABLED",
"notifications_configuration":"Not Present",
"metrics_monitoring_enabled":false,
"location":"eu-de",
"storage_class":"standard",
"deleteAuthZ":{
"action":"cloud-object-storage.bucket.delete_bucket",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35:bucket:debug-gcat-bucket1"
},
"subject":{
"userId":"IBMid-5500030TRE"
},
"allowed":true
},
"viewKeyAuthZ":{
"action":"cloud-object-storage.bucket.list_crk_id",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35:bucket:debug-gcat-bucket1"
},
"subject":{
"userId":"IBMid-5500030TRE"
},
"allowed":true
},
"publicAccessAuthZ":{
"action":"cloud-object-storage.object.get",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35:bucket:debug-gcat-bucket1"
},
"subject":{
"userId":"IBMid-NoAuth"
},
"allowed":false
},
"putPolicyAuthZ":{
"action":"iam.policy.create",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35::"
},
"subject":{
"userId":"IBMid-5500030TRE"
},
"allowed":true
},
"isKPEnabled":false,
"isCloudFunctionsEnabled":"disabled",
"key":{
}
},
{
"name":"debug-gcat-buckettwo2",
"creation_time":"06/05/2020 8:39:12 PM",
"is_legacy":false,
"has_activity_tracking":true,
"storage_location":"eu-de-standard",
"object_count":0,
"bytes_used":0,
"sse_kp_enabled":false,
"bucket_lifecycle_policy":"Not Present",
"bucket_protection_state":"DISABLED",
"notifications_configuration":"Not Present",
"metrics_monitoring_enabled":false,
"location":"eu-de",
"storage_class":"standard",
"deleteAuthZ":{
"action":"cloud-object-storage.bucket.delete_bucket",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35:bucket:debug-gcat-buckettwo2"
},
"subject":{
"userId":"IBMid-XXXXX"
},
"allowed":true
},
"viewKeyAuthZ":{
"action":"cloud-object-storage.bucket.list_crk_id",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35:bucket:debug-gcat-buckettwo2"
},
"subject":{
"userId":"IBMid-XXXXX"
},
"allowed":true
},
"publicAccessAuthZ":{
"action":"cloud-object-storage.object.get",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35:bucket:debug-gcat-buckettwo2"
},
"subject":{
"userId":"IBMid-NoAuth"
},
"allowed":false
},
"putPolicyAuthZ":{
"action":"iam.policy.create",
"resource":{
"crn":"crn:v1:bluemix:public:cloud-object-storage::a/67a4395fde4e4e0ca52f5554b249ceb7:1ded35ea-11df-47ab-9d0f-e28ebaacaf35::"
},
"subject":{
"userId":"IBMid-XXXXX"
},
"allowed":true
},
"isKPEnabled":false,
"isCloudFunctionsEnabled":"disabled",
"key":{
}
}
],
"is_truncated":false,
"limit":"20"
} |
@hkantare per the information @ifs-pauljegouic provided, the GUI is still able to get information regarding the buckets, even though he cannot access one of the buckets because his system ip is not whitelisted in the ip firewall. so is there some other API with the COS team that they are using in the GUI that allows them to get that information, that maybe the provider should be using instead? in the request paul posted, he is making a call to /objectstorage/api/v1/$CRN/buckets?tzOffset=-120&bss_account=accountid do you know if that is the same API that schematics is calling to grab the information? |
@kevinisninja The provider is using the https://github.com/IBM/ibm-cos-sdk-go/ below SDK to make calls to the API |
@kevinisninja This is the call failing when we add a firewall IP with 403 error code
|
@hkantare I talked with the COS team. They said that instead of using GetBucketLocation, you should be able to use ListBucketsExtendedOutput instead, and it will be able to provide you that information despite the IP firewall. From their perspective, the bucket list is supposed to be visible, only Object and Bucket operations should be blocked. Is it possible to refactor the provider code so that there will no longer be a 403 error? |
We changed to use ListBucketsExtendedOutput as per above comments.We are no longer getting 403 error now The fix is available in master will be part of next release(25th june) |
Great ! |
Fixed in latest release https://github.com/IBM-Cloud/terraform-provider-ibm/releases/tag/v1.8.0 Cloud docs Docs will be updated shortly |
Available in latest releases |
Does not work properly |
Can you explain the scenario or the steps in which its not working properly |
So here is the point @hkantare
Before, it was possible from the GUI to perform ** 2 **. Now it is not. Regarding ** 1 ** you have provided the ability to CREATE and READ Bucket Configuration, even if the IP is not allowed. UPDATE and DELETE is not allowed from a non-whitelisting IP. To be honest my engineer are completly lost, because we cannot understand what's the actual capability of COS. And there is the COS team quote:
We have tested to provision a bucket with authorized IPs.
This is leading me to the fact, that the AT and Sysdig information are not refreshed at all. |
Hi Pauljegouic, Executed following scenario to test the “COS bucket activity tracker and ip filtering configuration” CRUD functionalities and its observed that these operations are working as expected. Here are the steps and configurations that we have executed Steps Followed:
Configuration tf file resource "ibm_resource_instance" "cos_instance" { resource "ibm_resource_instance" "activity_tracker" { resource "ibm_resource_instance" "metrics_monitor" { resource "ibm_cos_bucket" "standard-ams03" { activity_tracking { metrics_monitoring { allowed_ip = [“169.60.175.87”] } Can you please share the steps that you executed. Thanks in advance. |
In fact, here is the need:
Right now, I understand, that it is not possible. I should have had a meeting this afternoon with COS Team, but it was cancelled. I agree that the asked capability cannot be implemented by the TF Team only.
Try to import an existing bucket Try to redo the same process: terraform init
terraform plan
terraform apply You will noticed that the plan does not see any changes. As my team is used to Terraform, this mean, that the configuration retrieved by TF Provider, is the same as the one informed in the input. So we thought that the behaviour expected was implemented. But in fact, it seems that the initial value is stored in the state, but is not refreshed with the actual configuration. Try to import an existing bucket Now perform From your local machine (which acts with configuration as our pipeline - not whitelisted), and it will fail. This prove that the In conclusion, this issue has been partially solved. (I think that all the misunderstood comes from the fact that this issue thread actually contains 2 issues ...) |
We are now closing the issue for now may be once we have updates from COS team you can open a new issue if it requires any changes from Terraform end.. |
Hi there,
We would like to be able to for each bucket to:
though the Terraform resource.
For now, we are using a null_resource that uses COS SDK.
The text was updated successfully, but these errors were encountered: