[pull] master from carlospolop:master

cloud-security/gcp-security/README.md

@@ -1,7 +1,5 @@
 # GCP Security
 
-![](<../../.gitbook/assets/image (629) (1) (1).png>)
-
 ## Security concepts <a href="#security-concepts" id="security-concepts"></a>
 
 ### **Resource hierarchy**
@@ -19,6 +17,14 @@ Organization
 
 A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.
 
+### **IAM Policies, Bindings and Memberships**
+
+In GCP there are different ways to grant a principal access over a resource:
+
+* **Memberships**: You set **principals as members of roles** **without restrictions** over the role or the principals. You can put a user as a member of a role and then put a group as a member of the same role and also set those principals (user and group) as member of other roles.
+* **Bindings**: Several **principals can be binded to a role**. Those **principals can still be binded or be members of other roles**. However, if a principal which isn’t binded to the role is set as **member of a binded role**, the next time the **binding is applied, the membership will disappear**.
+* **Policies**: A policy is **authoritative**, it indicates roles and principals and then, **those principals cannot have more roles and those roles cannot have more principals** unless that policy is modified (not even in other policies, bindings or memberships). Therefore, when a role or principal is specified in policy all its privileges are **limited by that policy**. Obviously, this can be bypassed in case the principal is given the option to modify the policy or privilege escalation permissions (like create a new principal and bind him a new role).
+
 ### **IAM Roles**
 
 There are **three types** of roles in IAM:
@@ -68,6 +74,10 @@ Or to see the IAM policy [assigned to a single Compute Instance](https://cloud.g
 gcloud compute instances get-iam-policy [INSTANCE] --zone [ZONE]
 ```
 
+### **Organization Policies**
+
+The IAM policies indicates the permissions principals has over resources via roles which ara assigned granular permissions. Organization policies **restrict how those service can be used or which features are enabled disabled**. This helps in order to improve the least privilege of each resource in the gcp environment.
+
 ### **Service accounts**
 
 Virtual machine instances are usually **assigned a service account**. Every GCP project has a [default service account](https://cloud.google.com/compute/docs/access/service-accounts#default\_service\_account), and this will be assigned to new Compute Instances unless otherwise specified. Administrators can choose to use either a custom account or no account at all. This service account **can be used by any user or application on the machine** to communicate with the Google APIs. You can run the following command to see what accounts are available to you:
@@ -138,14 +148,14 @@ The **metadata server** available to a given instance will **provide** any user/
 
 You can retrieve and inspect the token with the following curl command:
 
-```
-$ curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
+```bash
+curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
     -H "Metadata-Flavor: Google"
 ```
 
 Which will receive a response like the following:
 
-```
+```json
 {
       "access_token":"ya29.AHES6ZRN3-HlhAPya30GnW_bHSb_QtAS08i85nHq39HE3C2LTrCARA",
       "expires_in":3599,