{"id":4802,"date":"2020-10-27T18:27:53","date_gmt":"2020-10-27T21:27:53","guid":{"rendered":"https:\/\/www.dbarj.com.br\/?p=4802"},"modified":"2020-10-27T20:10:17","modified_gmt":"2020-10-27T23:10:17","slug":"why-you-should-avoid-giving-inspect-read-all-resources-policy-in-oci","status":"publish","type":"post","link":"https:\/\/www.dbarj.com.br\/en\/2020\/10\/why-you-should-avoid-giving-inspect-read-all-resources-policy-in-oci\/","title":{"rendered":"Why you should avoid giving inspect\/read all-resources policy in OCI"},"content":{"rendered":"

I’ve already seen many cases where a customer needs to give some read-only access on their tenancy to contractors \/ auditors \/ non-admin users. The easiest thing to is usually give “read” (or the more restrictive “inspect”) all-resources policy to that user’s group. In this article I will show how a user can use that to potentially expose some sensitive info from your company that you might not know.<\/p>\n

Getting started<\/h4>\n

First let’s say you give the more restrictive “inspect” instead of the “read” privilege.<\/span><\/p>\n\n\n\n\n\n\n
Verb<\/th>\nTypes of Access Covered<\/th>\nTarget User<\/th>\n<\/tr>\n<\/thead>\n
inspect<\/code><\/th>\nAbility to list resources, without access to any confidential information or user-specified metadata that may be part of that resource.\u00a0Important:<\/strong>\u00a0The operation to list policies includes the contents of the policies themselves, and the list operations for the\u00a0Networking<\/span>\u00a0resource-types return all the information (e.g., the contents of security lists and route tables).<\/td>\nThird-party auditors<\/span><\/td>\n<\/tr>\n
read<\/code><\/th>\nIncludes\u00a0inspect<\/code>\u00a0plus the ability to get user-specified metadata and the actual resource itself.<\/td>\nInternal auditors<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Source: https:\/\/docs.cloud.oracle.com\/en-us\/iaas\/Content\/Identity\/Concepts\/policies.htm<\/a><\/em><\/p>\n

So, in theory, inspect should not give you access to any confidential metadata. Let’s try however to create an inspect all-resources user to test it capabilities.<\/p>\n

In this demo I will create:<\/p>\n

User:<\/strong> oci_user_readonly
\nGroup:<\/strong> oci_group_readonly
\nPolicy:<\/strong> oci_policy_readonly ( “allow group oci_group_readonly to inspect any-resource on tenancy” )<\/p>\n

# Create User\r\noci iam user create --name oci_user_readonly --description \"OCI User with inspect all-resources.\"\r\n\r\n# Create Group\r\noci iam group create --name oci_group_readonly --description \"OCI Group with inspect all-resources.\"\r\n\r\n# Add User to Group\r\noci iam group add-user \\\r\n--user-id ocid1.user.oc1..aaaaaaaammz45b2fwiweoxyll6amqsrwpo7ll7fl2hymflogwxfrn4lhmara \\\r\n--group-id ocid1.group.oc1..aaaaaaaa5sipudlpetqo7sihu7schu6tpxkdygpf6iyxwki4yh3lsq66x5wq\r\n\r\n# Add Policy\r\noci iam policy add \\\r\n--compartment-id ocid1.tenancy.oc1..aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna \\\r\n--name oci_policy_readonly \\\r\n--description \"OCI Policy with inspect all-resources.\" \\\r\n--statements '[ \"allow group oci_group_readonly to inspect all-resources on tenancy\" ]'\r\n<\/pre>\n
Finally I will add a API Key on this “inspect-only”<\/strong> user and create a profile in my OCI-CLI named “INSPECT_ONLY”<\/strong> with this user credentials.<\/p>\n
Now, what if I configure this user and try to list some of the tenancy objects?<\/p>\n
$ oci --profile INSPECT_ONLY iam region-subscription list\r\n{\r\n  \"data\": [\r\n    {\r\n      \"is-home-region\": true,\r\n      \"region-key\": \"IAD\",\r\n      \"region-name\": \"us-ashburn-1\",\r\n      \"status\": \"READY\"\r\n    }\r\n  ]\r\n}<\/pre>\n
Great, my inspect-only user is working.. now going straight to the point of this article, what happens if I try to get the list of identity providers federated with my tenancy?<\/p>\n
$ oci --profile INSPECT_ONLY iam identity-provider list --protocol SAML2 --compartment-id ocid1.tenancy.oc1..aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna\r\n{\r\n  \"data\": [\r\n    {\r\n      \"compartment-id\": \"ocid1.tenancy.oc1..aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna\",\r\n      \"defined-tags\": {\r\n        \"Oracle-Tags\": {\r\n          \"CreatedBy\": \"organizationscontrolplane\",\r\n          \"CreatedOn\": \"2020-03-03T23:37:44.537Z\"\r\n        }\r\n      },\r\n      \"description\": \"Oracle identity cloud service added during account creation\",\r\n      \"freeform-attributes\": {\r\n        \"externalAppId\": \"69b3844f3c894f988398a32d16ca5cc7\",\r\n        \"externalClientId\": \"ocid1tenancyoc1aaaaaaaaunn73emggesayznwlqeunvmbsmbtgzbigd67mtjwbu2doq44igna_APPID\",\r\n        \"externalClientSecret\": \"316570c4-xxxx-xxxx-xxxx-xxxxxxxxxxxx\",\r\n        \"federationVersion\": \"2\"\r\n      },\r\n      \"freeform-tags\": {},\r\n      \"id\": \"ocid1.saml2idp.oc1..aaaaaaaauzu5s77yqfvvd6q6autpskl7tougpdwzmvuudmhblgfz2pp764sq\",\r\n      \"inactive-status\": null,\r\n      \"lifecycle-state\": \"ACTIVE\",\r\n      \"metadata-url\": \"https:\/\/idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com\",\r\n      \"name\": \"OracleIdentityCloudService\",\r\n      \"product-type\": \"IDCS\",\r\n      \"protocol\": \"SAML2\",\r\n      \"redirect-url\": \"https:\/\/idcs-8f223fded6c541f9b266c0901f3d5964.identity.oraclecloud.com\/fed\/v1\/idp\/sso\",\r\n      \"signing-certificate\": null,\r\n      \"time-created\": \"2020-03-03T23:37:44.552000+00:00\"\r\n    }\r\n  ]\r\n}<\/pre>\n
So, if we check the output above, there are 3 attributes that I consider “sensitive info”. Any user with inspect all-resources can retrieve:<\/p>\n