Merge pull request #155 from mosesrenegade/main

Added sections for GCP

Author: Frichetten

content/gcp/gcp-buckets.md

@@ -0,0 +1,25 @@
+---
+author: Moses Frost (@mosesrenegade)
+title: Hunting GCP Buckets
+description: How to find valid and invalid GCP Buckets using tools
+---
+
+GCP Buckets are almost 100% identical to AWS S3 Buckets. 
+
+*Theory*: This call is based on OpenStack; maybe most cloud environments will be the same.
+
+Using @digininja's [CloudStorageFinder](https://github.com/digininja/CloudStorageFinder) diff the following files:
+
+`diff bucket_finder.rb google_finder.rb`
+
+The main differences are the URLs:
+
+- AWS Supports HTTP and HTTPS
+- `AWS S3` URLs: `http://s3-region.amazonaws.com`, i.e.: `http://s3-eu-west-1.amazonaws.com`.
+- GCP Endpoint: `https://storage.googleapis.com`
+
+How to find buckets using CloudStorageFinder:
+
+Create a wordlist with any name; in our example, it is `wordlist.txt`.
+
+$ `ruby google_finder.rb wordlist.txt`

content/gcp/general-knowledge/default-account-names.md

@@ -0,0 +1,35 @@
+---
+author: Moses Frost (@mosesrenegade)
+title: Default Account Information
+description: Default information on how accounts and service accounts exist in GCP
+---
+
+# Service Accounts
+
+[Service accounts](https://cloud.google.com/iam/docs/service-accounts) are similar to Azure [Service Principals](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals). They can allow for programmatic access but also abuse. 
+
+[Information on Service Accounts](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)
+
+User-Created Service Account: `[email protected]`
+
+Using the format above, you can denote the following items:
+
+- `service-account-name`: This will tell you potentially what services this is for: `Bigtable-sa` or `compute-sa`
+- `project-id`: This will be the project identifier that the service account is for. You can set your `gcloud` configuration to this `project-id`. It will be numerical typically.
+
+## Default Service Account filename permutations: 
+
+* `serviceaccount.json`
+* `service_account.json`
+* `sa-private-key.json`
+* `service-account-file.json`
+
+## Application-Based Service Account:
+
+- `[email protected]`: Ths would be `project-id` value for App Engine or anything leveraging App Engine.
+- `[email protected]`: This service account is for Compute Engine where the `project-number-compute` will be: `project-id`-`compute`. I.E. `1234567-compute`.
+
+## How to use Service Accounts
+
+In a BASH (or equivalent) shell: `export GOOGLE_APPLICATION_CREDENTIALS="/home/user/Downloads/service-account-file.json"`
+

content/gcp/general-knowledge/security-and-constraints.md

@@ -0,0 +1,27 @@
+---
+author: Moses Frost (@mosesrenegade)
+title: Security and Constraints
+description: Security considerations and constraints that are unique to GCP
+---
+
+
+GCP Resources are typically placed into Projects. Projects are a mix of resource groups in Azure and Accounts in AWS. Projects can be either non-hierarchical or completely hierarchical. An operator can place security constraints on these projects to provide a baseline security policy. There are also Organization-wide policy constraints that apply to every project.
+
+# Examples
+
+From: [Organizational Policy Constraints](https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints)
+
+* constraints/iam.disableServiceAccountCreation : This can disable the overall creation of service accounts. Equivalent to Service Principals in Azure.
+* constraints/iam.disableServiceAccountKeyCreation : This constraint will disable the ability to create a service account key. This constraint would be helpful if you want service accounts but only want to use RSA-based authentication. 
+
+There are specific policies that are *not* retroactive. We can use these to our *advantage*. 
+
+1. `constraints/compute.requireShieldedVm`: If a compute node is already created and exists without this constraint applied, then this constraint will not be retroactive. You *must* delete the object and re-create it for it to enforce shielded VMs. 
+2. `constraints/compute.vmExternalIpAccess`: Consider the following scenario:
+    
+    - Constraint is based on the following permutation: `projects/PROJECT_ID/zones/ZONE/instances/INSTANCE`
+    - Constraint looks for the `name` of the machine in the `project` identifier specified in the specific `zone`
+    - If you can boot a VM with this specific set of criteria, then you can have a machine with an External IP Address
+    - Machine cannot already exist.
+3. `constraints/compute.vmCanIpForward`: Another Non Retroactive Setting. The machine must not exist before this setting is created. Once this is set, then machines will enforce this condition.
+