Keys, Roles, and Logging

A long-lived access key is a secret that stays valid until someone disables it. If that secret is committed to git, copied into a screenshot, or pasted into a ticket, anyone who can read the copy can call the cloud API as that identity — often from another country, without your laptop. Lesson 1’s WAF does not see a “hack.” It may not see the API at all. The fix is not a prettier .gitignore after the leak. The fix is: do not create standing keys unless a named job cannot use a role; never commit secrets; if a secret leaked, disable it on an account you own and rotate. Pasting live keys into cyberlium-lab notes fails this lesson the same way live passwords failed Module 6.

Grayhat “keys in GitHub” hunting against strangers is not homework. If you accidentally committed a key in a repo YOU own, disable and rotate on YOUR account — still not a tutorial in scraping the world’s git hosts. Legal line: original Cyberlium teaching mapped to the CEH v13 cloud-computing domain — not official EC-Council training, not a cert, not exam dumps.

sudo apt install python3

brew install python3

python3 - << 'PY'
from pathlib import Path
root = Path.home()/'cyberlium-lab'
hits = []
if root.exists():
for p in root.rglob('*'):
    if p.is_file() and p.stat().st_size < 200_000:
        t = p.read_text(encoding='utf-8', errors='ignore')
        if 'AKIA' in t and 'EXAMPLE' not in t:
            hits.append(str(p))
print('possible_standing_key_files', hits or 'none found in cyberlium-lab')
print('ethics: MY tree only — no GitHub dork of strangers')
PY

A role (or the equivalent: instance profile, workload identity, OIDC to a CI job) is a named job that can obtain temporary credentials when something you own proves it should. Those credentials expire. A stolen laptop then holds less of a standing door than a ten-year access key in a file named secrets.env. Humans should prefer console or SSO plus MFA over a personal access key. Workloads should prefer the provider’s role mechanism over a key baked into an image. You do not need an assume-role exploit chain to use that sentence. You need to prefer expiry.

Over-broad roles are still Lesson 2: a job that can do everything is standing admin with extra steps. Do not attach full administrator “so the demo works.” Do not mint a second long-lived key for class. Lesson 4 counts keys on identities you own. If you have no cloud, write: “no standing keys; CI would use a role; humans use MFA console.”

cat >> "$NOTES" << 'EOF'
prefer: roles and short-lived credentials
avoid: long-lived access key on disk/git
EOF

Audit logs (AWS CloudTrail is the famous name; other providers have equivalent trails) record management events: which identity created a key, who made a bucket public, where the API call appeared to come from. Conceptually that is a security camera for the control plane. Defenders use it to answer “did we do that?” after a surprise. This course names the camera. It does not teach you to wipe it, spoof it, or flood it. Module 6 already put tester documentation on the opposite side of covering tracks. The same sentence applies in cloud: on accounts you own, leave the trail on. On accounts you do not own, you do not touch logging.

You do not need a query cookbook aimed at someone else’s trail. Customer job: logging on, retained, readable by a named owner. Alerts like “new access key created” explain why Lesson 4 counts keys — not how to bypass them. If you own no account, write “hypothetical: trail on, root rare and MFA’d.” Do not disable logging on a shared family account “to see if anyone notices.”

Identities accumulate. An intern key from last year, a user who left, a second access key “for the laptop” that never got deleted — each is a door. Hygiene is a count: how many long-lived keys exist for users you own, which have not been used, which humans still have console without MFA. Lesson 4 is that count on a live account you own, or an honest skip. Today you write that unused is a finding without turning unused into a privilege-escalation lab against a tenant you do not administer.

Forbidden proofs: logging in as a classmate to list their keys; a work account without written permission; creating keys so the count is non-zero. If you find a key in YOUR old gist, disable it in YOUR console and do not paste the secret. chmod 600 on notes that even mention a rotation.

Other tenants’ IAM is out. Other tenants’ git is out as a hunting ground. Other tenants’ CloudTrail is out. “The API was reachable” is not consent — Module 1 already spent that sentence on public websites. Cloud control planes are public endpoints by design so customers can log in. That design is not a lab invitation. If you are unsure the account is yours, you stop. If you have no cloud, you still complete this lesson on definitions. Do not open a friend’s console to make logging feel real. Lesson 4 will say the same skip out loud.

Provider docs on enabling a trail or a role on an account you own are fair reading. Write-ups on stealing credentials from someone else’s app are not this course. If a sentence would help steal a key from a tenant you do not own, delete it. If it would help future-you keep YOUR account, keep it.

On a computer you own, create cyberlium-lab if needed. Fill the template. Do not paste access-key secrets. Do not add a git-dork kit. chmod 600. The block writes notes only.

You now treat standing cloud keys in git as a remote admin door, prefer roles that expire, and treat audit logs as a camera you leave on — on accounts you own. Hunting other people’s secrets is out. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 cloud-computing domain — not official EC-Council training, not a cert, not exam dumps. Next — Lab — IAM Hygiene on an Account You Own — MFA on root/console, list access keys you own, cloud-iam-lab.txt chmod 600, or skip with a hypothetical. Do not open a stranger’s console.