Cramsession - User contributions [en]

CyberSecurity/Soft Skills/Task Planning

2026-10-13T15:17:41Z

Mflavell: /* The Daily Operating Timeline */

= Operating Protocol: Work Planning & Execution =

This document outlines the standard operating procedure for converting high-level objectives into daily execution, ensuring continuous momentum while buffering against morning operational noise and ad-hoc requests.

__TOC__

== System Architecture ==

The workflow relies on a strict separation of concerns between storage and execution to prevent cognitive overload during deep work blocks.

* '''System of Record (Digital Task Manager / Jira):''' Holds the unedited inventory of tickets, monthly goals, study milestones, and backlog items. Manages dates, dependencies, and URLs.
* '''System of Execution (Kindle Scribe / Notebook):''' Dedicated solely to the current day's active execution and inbox scratchpad. Sits open on the desk as an immutable focus anchor.

== 1. Monthly Goals (The Compass) ==

Monthly goals define the broader strategic targets. These are directional and often represent complete project phases or certification milestones.

* '''Scope:''' 2 to 4 major objectives per month.
* '''Format:''' Outcome-based.
* '''Examples:''' "Complete Domain 4 of study curriculum," "Deploy upgraded WebDesk module," or "Finalize quarterly security audit."
* '''Review Cadence:''' Last Friday of the month.

== 2. Weekly MITs (The Quota) ==

Weekly Most Important Tasks (MITs) break monthly goals down into a 5-day quota. They define the required outcomes for a successful week but are not used as daily checklist items.

* '''Scope:''' 3 to 5 outcomes per week.
* '''Format:''' Quotas and deliverables.
* '''Examples:''' "Close 3 high-priority tickets," "Study 4 hours total," or "Draft initial remediation notes for new CVEs."
* '''Review Cadence:''' Sunday evening or Monday morning before operations begin.

== 3. Daily Execution (The Engine) ==

Daily tasks are concrete, non-negotiable execution blocks that advance the Weekly MITs. They must be defined by terminal actions (Draft, Submit, Review, Deploy) rather than open-ended time commitments.

=== The Daily Operating Timeline ===

To insulate the daily plan from early morning volatility, the daily lock occurs ''after'' the morning team sync.

{| class="wikitable"
|-
! Time !! Phase !! Action Protocol
|-
|06:00 -
07:00
|Fitness
|Morning workout
|-
| '''07:30 - 08:00''' || Daily standup || Do not edit the daily execution plan. Treat the call as an external audit. Log incoming requests, ticket mentions, or blockers purely as raw bullet points in the Scratchpad margin.
|-
| '''08:00 - 08:15''' || Triage & Lock || Run the Scratchpad through the impact filter (Blockers become Task #1; Actionable Work goes to digital backlog; Noise gets ignored). Write down the final 1-3 Daily Actions on the E-Paper. Lock the list. Assign calendar focus blocks based on estimated time.
|-
|9:00 -
9:30
|Fitness
|Morning walk
|-
|11:00 -
12:00
|Fitness break
|Exercise and lunch
|-
|15:00
|Shutdown
|No items unless emergency after 15:00
|}

=== Rules of Daily Engagement ===

# '''The Rule of 3:''' Commit to exactly 1 to 3 core actions per day. If these are completed, the day is a success regardless of incoming noise.
# '''Calendar Anchors:''' Quota-based tasks (e.g., studying) are protected calendar appointments, not checkbox items.
# '''Scratchpad Isolation:''' Ad-hoc requests received during the day are logged in the E-Paper margin, never added to the day's active execution list unless it is a P0 production blocker.

== 4. Evening Sweep (Shutdown Protocol) ==

At the end of the workday, perform a 5-minute staging routine to close out the current cycle and prepare the next.

# '''Process the Scratchpad:''' Move actionable margin notes into the digital task manager or Jira backlog.
# '''Clear the Board:''' Cross off completed daily items.
# '''Draft Candidates:''' Pencil in the 1-2 self-directed core actions for tomorrow on a fresh page. Do not finalize until the 07:30 post-standup lock tomorrow morning.

CyberSecurity/Soft Skills/Task Planning

2026-10-12T22:11:47Z

Mflavell:

= Operating Protocol: Work Planning & Execution =

This document outlines the standard operating procedure for converting high-level objectives into daily execution, ensuring continuous momentum while buffering against morning operational noise and ad-hoc requests.

__TOC__

== System Architecture ==

The workflow relies on a strict separation of concerns between storage and execution to prevent cognitive overload during deep work blocks.

* '''System of Record (Digital Task Manager / Jira):''' Holds the unedited inventory of tickets, monthly goals, study milestones, and backlog items. Manages dates, dependencies, and URLs.
* '''System of Execution (Kindle Scribe / Notebook):''' Dedicated solely to the current day's active execution and inbox scratchpad. Sits open on the desk as an immutable focus anchor.

== 1. Monthly Goals (The Compass) ==

Monthly goals define the broader strategic targets. These are directional and often represent complete project phases or certification milestones.

* '''Scope:''' 2 to 4 major objectives per month.
* '''Format:''' Outcome-based.
* '''Examples:''' "Complete Domain 4 of study curriculum," "Deploy upgraded WebDesk module," or "Finalize quarterly security audit."
* '''Review Cadence:''' Last Friday of the month.

== 2. Weekly MITs (The Quota) ==

Weekly Most Important Tasks (MITs) break monthly goals down into a 5-day quota. They define the required outcomes for a successful week but are not used as daily checklist items.

* '''Scope:''' 3 to 5 outcomes per week.
* '''Format:''' Quotas and deliverables.
* '''Examples:''' "Close 3 high-priority tickets," "Study 4 hours total," or "Draft initial remediation notes for new CVEs."
* '''Review Cadence:''' Sunday evening or Monday morning before operations begin.

== 3. Daily Execution (The Engine) ==

Daily tasks are concrete, non-negotiable execution blocks that advance the Weekly MITs. They must be defined by terminal actions (Draft, Submit, Review, Deploy) rather than open-ended time commitments.

=== The Daily Operating Timeline ===

To insulate the daily plan from early morning volatility, the daily lock occurs ''after'' the morning team sync.

{| class="wikitable"
|-
! Time !! Phase !! Action Protocol
|-
| '''06:30 - 07:00''' || Physical Reset & Prep || Zero work chat/email. Ground physical state. Open strictly to a blank E-Paper Scratchpad. Pre-draft a 30-second factual, metric-driven status update.
|-
| '''07:00 - 07:30''' || Call / Intake Buffer || Do not edit the daily execution plan. Treat the call as an external audit. Log incoming requests, ticket mentions, or blockers purely as raw bullet points in the Scratchpad margin.
|-
| '''07:30 - 07:35''' || Triage & Lock || Run the Scratchpad through the impact filter (Blockers become Task #1; Actionable Work goes to digital backlog; Noise gets ignored). Write down the final 1-3 Daily Actions on the E-Paper. Lock the list.
|}

=== Rules of Daily Engagement ===

# '''The Rule of 3:''' Commit to exactly 1 to 3 core actions per day. If these are completed, the day is a success regardless of incoming noise.
# '''Calendar Anchors:''' Quota-based tasks (e.g., studying) are protected calendar appointments, not checkbox items.
# '''Scratchpad Isolation:''' Ad-hoc requests received during the day are logged in the E-Paper margin, never added to the day's active execution list unless it is a P0 production blocker.

== 4. Evening Sweep (Shutdown Protocol) ==

At the end of the workday, perform a 5-minute staging routine to close out the current cycle and prepare the next.

# '''Process the Scratchpad:''' Move actionable margin notes into the digital task manager or Jira backlog.
# '''Clear the Board:''' Cross off completed daily items.
# '''Draft Candidates:''' Pencil in the 1-2 self-directed core actions for tomorrow on a fresh page. Do not finalize until the 07:30 post-standup lock tomorrow morning.

CyberSecurity/Soft Skills/Task Planning

2026-10-12T22:10:12Z

Mflavell: Created page with "= Operating Protocol: Work Planning & Execution = This document outlines the standard operating procedure for converting high-level objectives into daily execution, ensuring continuous momentum while buffering against morning operational noise and ad-hoc requests. __TOC__ == System Architecture == The workflow relies on a strict separation of concerns between storage and execution to prevent cognitive overload during deep work blocks. * '''System of Record (Digital..."

= Operating Protocol: Work Planning & Execution =

This document outlines the standard operating procedure for converting high-level objectives into daily execution, ensuring continuous momentum while buffering against morning operational noise and ad-hoc requests.

__TOC__

== System Architecture ==

The workflow relies on a strict separation of concerns between storage and execution to prevent cognitive overload during deep work blocks.

* '''System of Record (Digital Task Manager / Jira):''' Holds the unedited inventory of tickets, monthly goals, study milestones, and backlog items. Manages dates, dependencies, and URLs.
* '''System of Execution (Kindle Scribe / Notebook):''' Dedicated solely to the current day's active execution and inbox scratchpad. Sits open on the desk as an immutable focus anchor.

== 1. Monthly Goals (The Compass) ==

Monthly goals define the broader strategic targets. These are directional and often represent complete project phases or certification milestones.

* '''Scope:''' 2 to 4 major objectives per month.
* '''Format:''' Outcome-based.
* '''Examples:''' "Complete Domain 4 of study curriculum," "Deploy upgraded WebDesk module," or "Finalize quarterly security audit."
* '''Review Cadence:''' Last Friday of the month.

== 2. Weekly MITs (The Quota) ==

Weekly Most Important Tasks (MITs) break monthly goals down into a 5-day quota. They define the required outcomes for a successful week but are not used as daily checklist items.

* '''Scope:''' 3 to 5 outcomes per week.
* '''Format:''' Quotas and deliverables.
* '''Examples:''' "Close 3 high-priority tickets," "Study 4 hours total," or "Draft initial remediation notes for new CVEs."
* '''Review Cadence:''' Sunday evening or Monday morning before operations begin.

== 3. Daily Execution (The Engine) ==

Daily tasks are concrete, non-negotiable execution blocks that advance the Weekly MITs. They must be defined by terminal actions (Draft, Submit, Review, Deploy) rather than open-ended time commitments.

=== The Daily Operating Timeline ===

To insulate the daily plan from early morning volatility, the daily lock occurs ''after'' the morning team sync.

{| class="wikitable"
|-
! Time !! Phase !! Action Protocol
|-
| '''06:30 - 07:00''' || Physical Reset & Prep || Zero work chat/email. Ground physical state. Open strictly to a blank E-Paper Scratchpad. Pre-draft a 30-second factual, metric-driven status update.
|-
| '''07:00 - 07:30''' || Call / Intake Buffer || Do not edit the daily execution plan. Treat the call as an external audit. Log incoming requests, ticket mentions, or blockers purely as raw bullet points in the Scratchpad margin.
|-
| '''07:30 - 07:35''' || Triage & Lock || Run the Scratchpad through the impact filter (Blockers become Task #1; Actionable Work goes to digital backlog; Noise gets ignored). Write down the final 1-3 Daily Actions on the E-Paper. Lock the list.
|}

=== Rules of Daily Engagement ===

# '''The Rule of 3:''' Commit to exactly 1 to 3 core actions per day. If these are completed, the day is a success regardless of incoming noise.
# '''Calendar Anchors:''' Quota-based tasks (e.g., studying) are protected calendar appointments, not checkbox items.
# '''Scratchpad Isolation:''' Ad-hoc requests received during the day are logged in the E-Paper margin, never added to the day's active execution list unless it is a P0 production blocker.

== 4. Evening Sweep (Shutdown Protocol) ==

At the end of the workday, perform a 5-minute staging routine to close out the current cycle and prepare the next.

# '''Process the Scratchpad:''' Move actionable margin notes into the digital task manager or Jira backlog.
# '''Clear the Board:''' Cross off completed daily items.
# '''Draft Candidates:''' Pencil in the 1-2 self-directed core actions for tomorrow on a fresh page. Do not finalize until the 07:30 post-standup lock tomorrow morning.

Cybersecurity/Soft Skills

2026-10-12T22:09:13Z

Mflavell: Created page with "🗓️Task Planning"

🗓️[[CyberSecurity/Soft Skills/Task Planning|Task Planning]]

Cybersecurity

2026-10-12T22:07:40Z

Mflavell:

[https://www.cvedetails.com 🔍CVE Search]

[[Vulnerability tree |🌴Vulnerability tree]]

[[Pentesting |✒️Pentesting]]

[[Assessing Risk|😲Risk]]

[[The Dirty Dozen|✈️Dirty dozen]]

[[MTO triangle|📐Motive Technology Opportunity]]

[[North / South & East West Network Security |🧭North/South & East/West Movements]]

[https://cheatsheetseries.owasp.org/index.html 🐝OS Wasp Cheat Sheets]

[[Cyber Kill Chain|⛓️‍💥Cyber Kill Chain]]

[[Cybersecurity/AWS Cybersecurity papers|🌤️AWS Cybersecurity papers]]

🍦[[Cybersecurity/Soft Skills|Soft Skills]]

[https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF Memory Safe Development]

Ham Radio/SFO Approach

2026-10-08T20:28:10Z

Mflavell: Created page with "=== Garage G (International) Monitoring Setup === # '''Spotting Location:''' Drive up to '''Level 8 (Roof)''' and park along the '''northeast or east perimeter wall'''. This gives you an unobstructed line of sight down the 28 approaches, the taxiways, and the Terminal G gate gates. # '''Scanner Reception:''' From the open roof deck, you are no longer limited by distance or terrain. You will have full, clear two-way reception of both the controllers and the aircraft acro..."

=== Garage G (International) Monitoring Setup ===

# '''Spotting Location:''' Drive up to '''Level 8 (Roof)''' and park along the '''northeast or east perimeter wall'''. This gives you an unobstructed line of sight down the 28 approaches, the taxiways, and the Terminal G gate gates.
# '''Scanner Reception:''' From the open roof deck, you are no longer limited by distance or terrain. You will have full, clear two-way reception of both the controllers and the aircraft across all phases:
#* '''133.950 MHz''' (NorCal Arrival)
#* '''134.500 / 128.325 MHz''' (NorCal Vectors/Final)
#* '''120.500 MHz''' (SFO Tower)
#* '''121.800 MHz''' (SFO Ground)
#* '''131.000 MHz''' (United / SFO Ramp - Terminal G alley)
# '''Flight Tracker Cue:''' When checking FlightAware or FlightRadar24 while en route, watch for UA190 descending through FL240 (24,000 ft) offshore west of Marin County. That descent point signals that NorCal contact is about 5 minutes away.

Favorite list for Uniden Scanner:<blockquote>C-Group SFO Tower & Approach 0 0 0 0 0

C-Freq SFO NorCal Coast 133.950000 AM 0 0 0 0 1 0

C-Freq SFO NorCal Downwind 134.500000 AM 0 0 0 0 1 0

C-Freq SFO NorCal Vectors 128.325000 AM 0 0 0 0 1 0

C-Freq SFO Tower 28L/R 120.500000 AM 0 0 0 0 1 0

C-Freq SFO Ground 28s 121.800000 AM 0 0 0 0 1 0

C-Freq SFO West Ramp G 131.000000 AM 0 0 0 0 1 0</blockquote>

Ham Radio

2026-10-08T20:26:12Z

Mflavell:

= Uniden Scanner =
[[Ham Radio/Programming a Uniden SD card scanner without Windows|Programming a Uniden SD card scanner without Windows]]

[[Ham Radio/SFO Approach|SFO Approach]]

= Satelite =

[https://www.amsat.org/track/?lang=en&satellite=ISS ISS Pass Calculator]

[https://www.utctime.net/utc-time-zone-converter UTC Time Converter]

[https://www.ariss.org/current-status-of-iss-stations.html ISS Releater]

[https://www.amsat.org/status/ Satelite Status]

= Tools =

[https://www.swpc.noaa.gov Space Weather]

[https://www.qsl.net/w4sat/horizon.htm Line of siite calculator]

[https://vhf.dxview.org VHF Propagation map]

[[VV-898S Tips]]

= DMR =

[https://hose.brandmeister.network Brandmeister Hoseline]
[https://brandmeister.network/?page=talkgroups Talkgroups]

[[Brandmister essential talkgroups]]

[[BayNet]]

[[Anytone uv878]]

Ham Radio/Programming a Uniden SD card scanner without Windows

2026-10-08T20:25:00Z

Mflavell: Created page with "These models store their operating database and receive firmware updates directly through the microSD card. You '''do not need Windows''' for manual database updates or firmware flashing if you can obtain the raw payload file: '''1.Mount the SD Card:'''Linux or macOS. Power off the scanner, pop out the micro-SD card, and insert it directly into your Mac/Linux card reader (or plug the scanner in via USB and choose '''Mass Storage Mode'''). ''Verification:'' Check that..."

These models store their operating database and receive firmware updates directly through the microSD card. You '''do not need Windows''' for manual database updates or firmware flashing if you can obtain the raw payload file:

'''1.Mount the SD Card:'''Linux or macOS.

Power off the scanner, pop out the micro-SD card, and insert it directly into your Mac/Linux card reader (or plug the scanner in via USB and choose '''Mass Storage Mode''').

''Verification:'' Check that the volume mounts cleanly as a standard FAT32 drive showing a top-level directory named <code>BCDx36HP</code> or <code>HP1</code>.

'''2.Update Firmware (Offline BIN Method):'''No software required.

Uniden firmware payloads are standalone <code>.bin</code> files. Download the latest official firmware binary for your model (hosted on Uniden's support repos or community mirrors like RadioReference), copy the <code>.bin</code> file directly into the <code>/firmware</code> directory on the SD card root, and properly unmount/eject the disk.

''Verification:'' Disconnect and boot the scanner on battery/wall power. The display will immediately show a progress bar reading ''“Applying Firmware Update”''.

'''3.Update Database (Weekly RadioReference HPDB):'''Native Python script.

Community Python utilities (such as <code>uniden-hpdb-sync</code>) can pull the weekly Master HPDB directly from Uniden’s CDN, unpack the encryption/delta, and write it straight to the SD card's <code>HPDB/</code> directory natively on macOS or Linux without Sentinel.

''Verification:'' Boot the scanner and check <code>Menu</code> → <code>Settings</code> → <code>See Scanner Info</code> to verify the DB date stamp advances.

'''4.Favorite Lists & Programming:'''Direct file editing.

Favorites lists on these models are plain-text config files inside the <code>/favorite_lists</code> folder. You can edit them using any standard text editor or write lightweight scripts to inject frequencies directly into the configuration files.

Ham Radio

2026-10-08T20:24:25Z

Mflavell:

= Uniden Scanner =
[[Ham Radio/Programming a Uniden SD card scanner without Windows|Programming a Uniden SD card scanner without Windows]]

= Satelite =

[https://www.amsat.org/track/?lang=en&satellite=ISS ISS Pass Calculator]

[https://www.utctime.net/utc-time-zone-converter UTC Time Converter]

[https://www.ariss.org/current-status-of-iss-stations.html ISS Releater]

[https://www.amsat.org/status/ Satelite Status]

= Tools =

[https://www.swpc.noaa.gov Space Weather]

[https://www.qsl.net/w4sat/horizon.htm Line of siite calculator]

[https://vhf.dxview.org VHF Propagation map]

[[VV-898S Tips]]

= DMR =

[https://hose.brandmeister.network Brandmeister Hoseline]
[https://brandmeister.network/?page=talkgroups Talkgroups]

[[Brandmister essential talkgroups]]

[[BayNet]]

[[Anytone uv878]]

Ham Radio\Uniden scanner programming

2026-10-08T20:22:06Z

Mflavell:

Ham Radio\Uniden scanner programming

2026-10-08T20:21:20Z

Ham Radio

2026-10-08T20:19:11Z

Mflavell:

= Uniden Scanner =
[[Ham Radio\Uniden scanner programming|Programming a Uniden SD card scanner without Windows]]

= Satelite =

[https://www.amsat.org/track/?lang=en&satellite=ISS ISS Pass Calculator]

[https://www.utctime.net/utc-time-zone-converter UTC Time Converter]

[https://www.ariss.org/current-status-of-iss-stations.html ISS Releater]

[https://www.amsat.org/status/ Satelite Status]

= Tools =

[https://www.swpc.noaa.gov Space Weather]

[https://www.qsl.net/w4sat/horizon.htm Line of siite calculator]

[https://vhf.dxview.org VHF Propagation map]

[[VV-898S Tips]]

= DMR =

[https://hose.brandmeister.network Brandmeister Hoseline]
[https://brandmeister.network/?page=talkgroups Talkgroups]

[[Brandmister essential talkgroups]]

[[BayNet]]

[[Anytone uv878]]

Cybersecurity/AWS Cybersecurity papers/S3 File Retention

2026-10-07T03:10:26Z

Mflavell:

== Introduction ==
'''In many instances, businesses are mandated to maintain immutable files for a specified duration to ensure regulatory, legal, and internal audit compliance. This guide offers an overview of the available models in S3 and provides guidance on their implementation.'''

=== Three models for data retention ===
The first important concept to grasp is AWS S3 offers three models for data retention;

* '''Legal Hold''' acts as a manual, indefinite ON/OFF toggle that protects an object from deletion or modification until an authorized user explicitly turns it off, entirely independent of any time-based settings.

* '''Governance Mode''' provides the same time-based WORM protection as "Compliance mode" below but includes an administrative escape hatch, allowing users with specific IAM privileges to bypass the lock, alter the retention period, or delete the file when internal operational policies require flexibility.

* '''Compliance Mode''' is strictly immutable; absolutely no user—including the AWS account root user—can shorten the retention period or delete the object until that specific timestamp passes, satisfying stringent regulatory mandates like SEC or FINRA.

Simply, legal hold is the most permissive - Governance mode provides a middle ground - Complance mode provide strict structure.

=== Consider storage costs ===

==== The Accumulation of Compliance Data ====
Once an organization implements stringent legal holds and WORM (Write-Once-Read-Many) compliance rules, data retention is no longer a choice—it is a mandate. For security teams and system architects, this means years of audit trails, application logs, and large infrastructure backups (such as heavy <code>.ova</code> virtual machine images or database snapshots) must be preserved without modification. Storing this ever-growing mountain of immutable data in the S3 Standard storage class quickly becomes a significant financial burden. Because compliance data is written once and rarely—if ever—read again, paying premium rates for millisecond access to petabytes of static files is an architectural anti-pattern.

==== Automating the Descent with Lifecycle Policies ====
The solution to cost-effective long-term retention is not manual data migration, but automated S3 Lifecycle Policies. AWS allows engineers to define rule sets that automatically cascade objects into progressively cheaper storage tiers as they age. For example, a web application's access log might sit in S3 Standard for the first 30 days when it is most likely to be queried during an active incident response. Afterward, a lifecycle rule can automatically transition it to Standard-Infrequent Access (Standard-IA) for 60 days, before finally pushing it into cold storage.

==== S3 Glacier Deep Archive: The Final Resting Place ====
For data that must be retained for 7 to 10 years strictly for regulatory compliance or absolute worst-case disaster recovery, S3 Glacier Deep Archive represents the floor for AWS storage pricing. It is designed specifically for data that is accessed less than once a year. The trade-off for its drastically reduced storage cost—often fractions of a cent per gigabyte—is retrieval latency. Unlike S3 Standard, pulling an object from Deep Archive requires initiating a restoration job that can take up to 12 hours for standard retrieval. This paradigm forces architects to decouple the concept of "storage" from "immediate availability," treating Deep Archive as a true digital vault where data is locked away rather than actively hosted.

==== Storage Class Comparison ====
{| class="wikitable"
|+
!Storage Class
!Primary Use Case
!Relative Cost (per GB/mo)
!Retrieval Time
|-
|S3 Standard
|Active, frequently accessed data, ongoing projects
|Premium (~$0.023)
|Milliseconds
|-
|S3 Glacier Flexible Retrieval
|Backups and archives accessed 1–2 times a year
|Low (~$0.0036)
|1 minute to 12 hours
|-
|S3 Glacier Deep Archive
|Long-term compliance, WORM data, digital preservation
|Lowest (~$0.00099)
|12 to 48 hours
|}

==== Removing Guesswork with S3 Intelligent-Tiering ====
While strict lifecycle policies excel at archiving predictable compliance data, modern workloads rarely follow a clean, linear decay. Consider a data lake containing both WORM-protected audit logs and active security analytics. An auditor might suddenly need to query a six-month-old log file that a rigid lifecycle rule already buried in Glacier. If you retrieve that file from a standard Glacier class, you incur per-GB retrieval fees and wait hours. If you leave everything in S3 Standard just in case, your storage bill skyrockets.

S3 Intelligent-Tiering solves this by decoupling cost optimization from manual lifecycle management. It is a storage class that automatically monitors access patterns and moves objects between distinct access tiers without operational overhead or retrieval fees.
[[File:Aws Intelligent-Tiering.png|center|Intelligent-Tiering |frame]]
Intelligent-Tiering evaluates objects at the individual level and transitions them through up to five tiers:

# '''Frequent Access Tier:''' The default landing zone, priced identically to S3 Standard.
# '''Infrequent Access Tier:''' Objects not accessed for 30 consecutive days are moved here, saving roughly 40% on storage.
# '''Archive Instant Access Tier:''' Objects not accessed for 90 days are moved here, saving roughly 68%. Like the previous tiers, data here still features millisecond retrieval times.
# '''Archive Access Tier (Optional):''' You can configure Intelligent-Tiering to move objects here after 90 to 730 days of inactivity. It mirrors standard Glacier pricing and retrieval times (minutes to hours).
# '''Deep Archive Access Tier (Optional):''' The final tier for objects untouched for 180 to 730 days, mirroring Glacier Deep Archive.

The moment an object in ''any'' of these tiers is accessed, AWS automatically moves it back to the Frequent Access tier. The financial trade-off is a small monthly monitoring and automation fee per 1,000 objects. For buckets containing large files (like <code>.ova</code> images or database snapshots), the storage savings from dropping into the Infrequent or Archive Instant tiers drastically outweigh the microscopic monitoring fee.

Crucially for compliance architectures, '''S3 Object Lock is fully supported on Intelligent-Tiering'''. You can apply Legal Holds and Compliance Mode retention periods to objects while letting AWS automatically sink them into the cheapest storage tiers over time, guaranteeing immutability without sacrificing cost efficiency.

Cybersecurity/AWS Cybersecurity papers/S3 File Retention

2026-10-07T03:09:42Z

Mflavell: Created page with "== Introduction == '''In many instances, businesses are mandated to maintain immutable files for a specified duration to ensure regulatory, legal, and internal audit compliance. This guide offers an overview of the available models in S3 and provides guidance on their implementation.''' === Three models for data retention === The first important concept to grasp is AWS S3 offers three models for data retention; * '''Legal Hold''' acts as a manual, indefinite ON/OFF tog..."

== Introduction ==
'''In many instances, businesses are mandated to maintain immutable files for a specified duration to ensure regulatory, legal, and internal audit compliance. This guide offers an overview of the available models in S3 and provides guidance on their implementation.'''

=== Three models for data retention ===
The first important concept to grasp is AWS S3 offers three models for data retention;

* '''Legal Hold''' acts as a manual, indefinite ON/OFF toggle that protects an object from deletion or modification until an authorized user explicitly turns it off, entirely independent of any time-based settings.

* '''Governance Mode''' provides the same time-based WORM protection as "Compliance mode" below but includes an administrative escape hatch, allowing users with specific IAM privileges to bypass the lock, alter the retention period, or delete the file when internal operational policies require flexibility.

* '''Compliance Mode''' is strictly immutable; absolutely no user—including the AWS account root user—can shorten the retention period or delete the object until that specific timestamp passes, satisfying stringent regulatory mandates like SEC or FINRA.

Simply, legal hold is the most permissive - Governance mode provides a middle ground - Complance mode provide strict structure.

=== Consider storage costs ===

==== The Accumulation of Compliance Data ====
Once an organization implements stringent legal holds and WORM (Write-Once-Read-Many) compliance rules, data retention is no longer a choice—it is a mandate. For security teams and system architects, this means years of audit trails, application logs, and large infrastructure backups (such as heavy <code>.ova</code> virtual machine images or database snapshots) must be preserved without modification. Storing this ever-growing mountain of immutable data in the S3 Standard storage class quickly becomes a significant financial burden. Because compliance data is written once and rarely—if ever—read again, paying premium rates for millisecond access to petabytes of static files is an architectural anti-pattern.

==== Automating the Descent with Lifecycle Policies ====
The solution to cost-effective long-term retention is not manual data migration, but automated S3 Lifecycle Policies. AWS allows engineers to define rule sets that automatically cascade objects into progressively cheaper storage tiers as they age. For example, a web application's access log might sit in S3 Standard for the first 30 days when it is most likely to be queried during an active incident response. Afterward, a lifecycle rule can automatically transition it to Standard-Infrequent Access (Standard-IA) for 60 days, before finally pushing it into cold storage.

==== S3 Glacier Deep Archive: The Final Resting Place ====
For data that must be retained for 7 to 10 years strictly for regulatory compliance or absolute worst-case disaster recovery, S3 Glacier Deep Archive represents the floor for AWS storage pricing. It is designed specifically for data that is accessed less than once a year. The trade-off for its drastically reduced storage cost—often fractions of a cent per gigabyte—is retrieval latency. Unlike S3 Standard, pulling an object from Deep Archive requires initiating a restoration job that can take up to 12 hours for standard retrieval. This paradigm forces architects to decouple the concept of "storage" from "immediate availability," treating Deep Archive as a true digital vault where data is locked away rather than actively hosted.

==== Storage Class Comparison ====
{| class="wikitable"
|+
!Storage Class
!Primary Use Case
!Relative Cost (per GB/mo)
!Retrieval Time
|-
|S3 Standard
|Active, frequently accessed data, ongoing projects
|Premium (~$0.023)
|Milliseconds
|-
|S3 Glacier Flexible Retrieval
|Backups and archives accessed 1–2 times a year
|Low (~$0.0036)
|1 minute to 12 hours
|-
|S3 Glacier Deep Archive
|Long-term compliance, WORM data, digital preservation
|Lowest (~$0.00099)
|12 to 48 hours
|}

==== Removing Guesswork with S3 Intelligent-Tiering ====
While strict lifecycle policies excel at archiving predictable compliance data, modern workloads rarely follow a clean, linear decay. Consider a data lake containing both WORM-protected audit logs and active security analytics. An auditor might suddenly need to query a six-month-old log file that a rigid lifecycle rule already buried in Glacier. If you retrieve that file from a standard Glacier class, you incur per-GB retrieval fees and wait hours. If you leave everything in S3 Standard just in case, your storage bill skyrockets.

S3 Intelligent-Tiering solves this by decoupling cost optimization from manual lifecycle management. It is a storage class that automatically monitors access patterns and moves objects between distinct access tiers without operational overhead or retrieval fees.
[[File:Aws Intelligent-Tiering.png|center|thumb|Intelligent-Tiering ]]
Intelligent-Tiering evaluates objects at the individual level and transitions them through up to five tiers:

# '''Frequent Access Tier:''' The default landing zone, priced identically to S3 Standard.
# '''Infrequent Access Tier:''' Objects not accessed for 30 consecutive days are moved here, saving roughly 40% on storage.
# '''Archive Instant Access Tier:''' Objects not accessed for 90 days are moved here, saving roughly 68%. Like the previous tiers, data here still features millisecond retrieval times.
# '''Archive Access Tier (Optional):''' You can configure Intelligent-Tiering to move objects here after 90 to 730 days of inactivity. It mirrors standard Glacier pricing and retrieval times (minutes to hours).
# '''Deep Archive Access Tier (Optional):''' The final tier for objects untouched for 180 to 730 days, mirroring Glacier Deep Archive.

The moment an object in ''any'' of these tiers is accessed, AWS automatically moves it back to the Frequent Access tier. The financial trade-off is a small monthly monitoring and automation fee per 1,000 objects. For buckets containing large files (like <code>.ova</code> images or database snapshots), the storage savings from dropping into the Infrequent or Archive Instant tiers drastically outweigh the microscopic monitoring fee.

Crucially for compliance architectures, '''S3 Object Lock is fully supported on Intelligent-Tiering'''. You can apply Legal Holds and Compliance Mode retention periods to objects while letting AWS automatically sink them into the cheapest storage tiers over time, guaranteeing immutability without sacrificing cost efficiency.

File:Aws Intelligent-Tiering.png

2026-10-07T03:08:35Z

Mflavell:

AWS Intelligent-Tiering

Cybersecurity/AWS Cybersecurity papers

2026-10-07T02:31:35Z

Mflavell:

[[Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example|AWS Secrets Example]]

[[Cybersecurity/AWS Cybersecurity papers/S3 File Retention|File retention in S3]]

Cybersecurity

2026-10-07T02:30:21Z

Mflavell:

[https://www.cvedetails.com 🔍CVE Search]

[[Vulnerability tree |🌴Vulnerability tree]]

[[Pentesting |✒️Pentesting]]

[[Assessing Risk|😲Risk]]

[[The Dirty Dozen|✈️Dirty dozen]]

[[MTO triangle|📐Motive Technology Opportunity]]

[[North / South & East West Network Security |🧭North/South & East/West Movements]]

[https://cheatsheetseries.owasp.org/index.html 🐝OS Wasp Cheat Sheets]

[[Cyber Kill Chain|⛓️‍💥Cyber Kill Chain]]

[[Cybersecurity/AWS Cybersecurity papers|🌤️AWS Cybersecurity papers]]

[https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF Memory Safe Development]

Cybersecurity

2026-10-07T02:29:47Z

Mflavell:

[https://www.cvedetails.com 🔍CVE Search]

[[Vulnerability tree |🌴Vulnerability tree]]

[[Pentesting |✒️Pentesting]]

[[Assessing Risk|😲Risk]]

[[The Dirty Dozen|✈️Dirty dozen]]

[[MTO triangle|📐Motive Technology Opportunity]]

[[North / South & East West Network Security |🧭North/South & East/West Movements]]

[https://cheatsheetseries.owasp.org/index.html 🐝OS Wasp Cheat Sheets]

[[Cyber Kill Chain|⛓️‍💥Cyber Kill Chain]]

[[Cybersecurity/AWS Cybersecurity papers|☁️AWS Cybersecurity papers]]

[https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF Memory Safe Development]

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

2026-10-06T21:35:30Z

Mflavell: /* AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles */

== AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles ==

=== Overview ===
Storing secrets outside of source code and configuration files is a conerstone of cybersecurity. Fortunatley AWS includeds "AWS Secrets Manger" intended for this purpose.

Some of the KEY features of AWS Secrets manager are:

* Granular access controls
* Auduable access (Know who, what and when)
* Secret history
* Seemless intergration with AWS services
* Regional replication

This paper provides a demonstration of securing secrets with AWS Serets manager.

=== Step 1: Create the secret ===

# From AWS console open secerts manager.
# Select '''Other type of secret'''
# Use the "Key / Value" Option
# Provice and key and a value
# Click next
# Provice a name for the secret
# Click next
# Turn on (or off) automatic rotation
# Click next
# Click store

Great! Now we have a secret!. However nothing will work without IAM permissions!

=== Step 2: Configure IAM Permissions and Instance Profile ===

# Open EC2, Select Instances
# Open your sandbox EC2 instance
# Select Actions > Security > Modift IAM Role
# Select "Create IAM Role"
# Let's call the role "Secret_read"
# Select "Use Existing Policy"
# Select "AWSSecretsManagerClientReadOnlyAccess"
# Select "Create Role"<br />

=== Step 3: Setup the sandbox ===

==== 1. Verify IMDSv2 Credential Acquisition ====
lets do this on Amazon Linux - Much easier!

'''Install python:'''
sudo dnf update -y
sudo dnf install -y python3 python3-pip
python3 --version
pip3 --version

'''<br />Create the v-env:'''

mkdir ~/secrets-lab && cd ~/secrets-lab
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install boto3

==== Step 4: Create the code ====
Create the test code, fetch.py
import json
import boto3

client = boto3.client("secretsmanager", region_name="us-east-1")

payload = {
"username": "db_admin",
"password": "SuperSecretPassword123!",
"host": "mydb.internal",
}
response = client.create_secret(
Name="app/database_creds",
Description="Application DB Credentials",
SecretString=json.dumps(payload),
)

print(f"Created secret ARN: {response['ARN']}")

==== Step 5: Run the code ====
python3 fetch.py

{'Test': 'This is secret'}

==== Step 5: Lab Teardown & Cost Management ====
AWS Secrets Manager incurs $0.40/secret/month (prorated hourly). To prevent ongoing charges after completing lab tests, force-delete the secret without entering the default recovery retention period:

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

2026-10-06T21:34:24Z

Mflavell: /* 1. Verify IMDSv2 Credential Acquisition */

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

2026-10-06T21:33:07Z

Mflavell: /* Step 3: Setup the sandbox */

== AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles ==

=== Overview ===
Storing secrets outside of source code and configuration files is a conerstone of cybersecurity. Fortunatley AWS includeds "AWS Secrets Manger" intended for this purpose.

Some of the KEY features of AWS Secrets manager are:

* Granular access controls
* Auduable access (Know who, what and when)
* Secret history
* Seemless intergration with AWS services
* Regional replication

This paper provides a demonstration of securing secrets with AWS Serets manager.

=== Step 1: Create the secret ===

# From AWS console open secerts manager.
# Select '''Other type of secret'''
# Use the "Key / Value" Option
# Provice and key and a value
# Click next
# Provice a name for the secret
# Click next
# Turn on (or off) automatic rotation
# Click next
# Click store

Great! Now we have a secret!. However nothing will work without IAM permissions!

=== Step 2: Configure IAM Permissions and Instance Profile ===

# Open EC2, Select Instances
# Open your sandbox EC2 instance
# Select Actions > Security > Modift IAM Role
# Select "Create IAM Role"
# Let's call the role "Secret_read"
# Select "Use Existing Policy"
# Select "AWSSecretsManagerClientReadOnlyAccess"
# Select "Create Role"<br />

=== Step 3: Setup the sandbox ===

==== 1. Verify IMDSv2 Credential Acquisition ====
lets do this on Amazon Linuz - Much easier!

Install python:
sudo dnf update -y
sudo dnf install -y python3 python3-pip
python3 --version
pip3 --version

Crearte the v-env:

mkdir ~/secrets-lab && cd ~/secrets-lab
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install boto3

==== Step 4: Create the code ====
Create the test code, fetch.py
import json
import boto3

client = boto3.client("secretsmanager", region_name="us-east-1")

payload = {
"username": "db_admin",
"password": "SuperSecretPassword123!",
"host": "mydb.internal",
}
response = client.create_secret(
Name="app/database_creds",
Description="Application DB Credentials",
SecretString=json.dumps(payload),
)

print(f"Created secret ARN: {response['ARN']}")

==== Step 5: Run the code ====
python3 fetch.py

{'Test': 'This is secret'}

==== Step 5: Lab Teardown & Cost Management ====
AWS Secrets Manager incurs $0.40/secret/month (prorated hourly). To prevent ongoing charges after completing lab tests, force-delete the secret without entering the default recovery retention period:

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

2026-10-06T02:54:28Z

Mflavell: /* Overview */

== AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles ==

=== Overview ===
Storing secrets outside of source code and configuration files is a conerstone of cybersecurity. Fortunatley AWS includeds "AWS Secrets Manger" intended for this purpose.

Some of the KEY features of AWS Secrets manager are:

* Granular access controls
* Auduable access (Know who, what and when)
* Secret history
* Seemless intergration with AWS services
* Regional replication

This paper provides a demonstration of securing secrets with AWS Serets manager.

=== Step 1: Create the secret ===

# From AWS console open secerts manager.
# Select '''Other type of secret'''
# Use the "Key / Value" Option
# Provice and key and a value
# Click next
# Provice a name for the secret
# Click next
# Turn on (or off) automatic rotation
# Click next
# Click store

Great! Now we have a secret!. However nothing will work without IAM permissions!

=== Step 2: Configure IAM Permissions and Instance Profile ===

# Open EC2, Select Instances
# Open your sandbox EC2 instance
# Select Actions > Security > Modift IAM Role
# Select "Create IAM Role"
# Let's call the role "Secret_read"
# Select "Use Existing Policy"
# Select "AWSSecretsManagerClientReadOnlyAccess"
# Select "Create Role"<br />

=== Step 3: Setup the sandbox ===

==== 1. Verify IMDSv2 Credential Acquisition ====
lets do this on Amazon Linuz - Much easier!

Install python:
sudo dnf update -y

sudo dnf install -y python3 python3-pip

python3 --version

pip3 --version

Crearte the v-env:

mkdir ~/secrets-lab && cd ~/secrets-lab

python3 -m venv venv

source venv/bin/activate

pip install --upgrade pip

pip install boto3

==== Step 4: Create the code ====
Create the test code, fetch.py
import json

import boto3

client = boto3.client("secretsmanager", region_name="us-east-1")

payload = {

"username": "db_admin",

"password": "SuperSecretPassword123!",

"host": "mydb.internal",

}

response = client.create_secret(

Name="app/database_creds",

Description="Application DB Credentials",

SecretString=json.dumps(payload),

)

print(f"Created secret ARN: {response['ARN']}")

==== Step 5: Run the code ====
python3 fetch.py

{'Test': 'This is secret'}

==== Step 5: Lab Teardown & Cost Management ====
AWS Secrets Manager incurs $0.40/secret/month (prorated hourly). To prevent ongoing charges after completing lab tests, force-delete the secret without entering the default recovery retention period:

Cybersecurity/AWS Cybersecurity papers

2026-10-06T02:09:18Z

Mflavell:

[[Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example|AWS Secrets Example]]

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles

2026-10-06T02:06:43Z

Mflavell: Mflavell moved page Cybersecurity/AWS Cybersecurity papers/AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles to Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

#REDIRECT [[Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example]]

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

2026-10-06T02:06:42Z

Mflavell: Mflavell moved page Cybersecurity/AWS Cybersecurity papers/AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles to Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

== AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles ==

=== Overview ===
This guide details the end-to-end setup for creating a secret in AWS Secrets Manager, granting access to an Amazon EC2 instance using an IAM instance profile (eliminating hardcoded credentials), configuring a Python runtime environment on Amazon Linux, and retrieving the secret payload programmatically using boto3.

=== Architecture & Security Model ===

* '''AWS Secrets Manager''': Stores sensitive configuration data encrypted at rest with AWS KMS.
* '''IAM Instance Profile''': Temporary security credentials rotated automatically via the EC2 Instance Metadata Service (IMDSv2). No static AWS access keys are stored on the instance.
* '''Principle of Least Privilege''': The IAM role permissions are restricted strictly to the secretsmanager:GetSecretValue action on the target secret resource ARN.

---

=== Step 1: Create the Secret in AWS Secrets Manager ===

Execute the following command via AWS CLI (or deploy via the AWS Management Console) to generate the secret with a JSON payload:

Note the generated '''ARN''' from the output:

arn:aws:secretsmanager:us-east-1:843771826066:secret:test/secret-cK45Ko

---

=== Step 2: Configure IAM Permissions and Instance Profile ===

==== 1. Create the IAM Role Trust Policy ====
Save the following trust policy document as ec2-trust-policy.json:

Create the role:

aws iam create-role

--role-name EC2-SecretsManager-ReadOnly

--assume-role-policy-document file://ec2-trust-policy.json

==== 2. Create and Attach the Least-Privilege IAM Policy ====
Save the permissions policy as secrets-policy.json, locking the resource down to the target secret ARN:

Attach the policy:

aws iam put-role-policy

--role-name EC2-SecretsManager-ReadOnly

--policy-name SecretsManagerAccessPolicy

--policy-document file://secrets-policy.json

==== 3. Create the Instance Profile and Attach to EC2 ====

# Create instance profile and add the role

aws iam create-instance-profile --instance-profile-name EC2-SecretsManager-Profile
aws iam add-role-to-instance-profile

--instance-profile-name EC2-SecretsManager-Profile

--role-name EC2-SecretsManager-ReadOnly

# Attach to the running EC2 instance

aws ec2 associate-iam-instance-profile

--instance-id <YOUR_INSTANCE_ID>

--iam-instance-profile Name=EC2-SecretsManager-Profile

''Note: In the AWS Console, this can also be applied via: '''EC2 Console''' -> Select Instance -> '''Actions''' -> '''Security''' -> '''Modify IAM role'''.''

---

=== Step 3: EC2 System & Python Environment Setup ===

Log in to the Amazon Linux instance and configure the runtime.

==== 1. Verify IMDSv2 Credential Acquisition ====
Confirm the instance profile is detected:

TOKEN=$(curl -s -S -X PUT "[http://169.254.169.254/latest/api/token](https://www.google.com/search?q=http://169.254.169.254/latest/api/token)" -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" [http://169.254.169.254/latest/meta-data/iam/security-credentials/](https://www.google.com/search?q=http://169.254.169.254/latest/meta-data/iam/security-credentials/)

The command should return: EC2-SecretsManager-ReadOnly.

==== 2. Install Packages & Virtual Environment ====

# Amazon Linux 2023:

sudo dnf update -y
sudo dnf install -y python3 python3-pip

# Amazon Linux 2:

# sudo yum update -y && sudo yum install -y python3 python3-pip

# Set up project workspace

mkdir ~/secrets-lab && cd ~/secrets-lab
python3 -m venv venv
source venv/bin/activate

# Install AWS SDK

pip install --upgrade pip
pip install boto3

---

=== Step 4: Python Retrieval Script ===

Create fetch.py.

''Note on Python compatibility:'' Including from **future** import annotations ensures the union type syntax (dict | str) parses cleanly across Python 3.7+ through 3.9 environments without throwing TypeError: unsupported operand type(s) for |: 'type' and 'type'.

import json
import boto3
from botocore.exceptions import ClientError

def get_secret(secret_name: str, region_name: str = "us-east-1") -> dict | str:
"""Retrieve and parse secret from AWS Secrets Manager using IAM instance credentials."""
session = boto3.session.Session()
client = session.client(
service_name="secretsmanager",
region_name=region_name,
)

```
try:
response = client.get_secret_value(SecretId=secret_name)
except ClientError as e:
raise e

if "SecretString" in response:
secret = response["SecretString"]
try:
return json.loads(secret)
except json.JSONDecodeError:
return secret

return response["SecretBinary"]

```

if **name** == "**main**":
SECRET_ID = "arn:aws:secretsmanager:us-east-1:843771826066:secret:test/secret-cK45Ko"
REGION = "us-east-1"

```
credentials = get_secret(SECRET_ID, region_name=REGION)
print("Successfully retrieved credentials payload:")
print(credentials)

```

==== Execution and Verification ====

(venv) [ec2-user@ip-10-0-0-5 secrets-lab]$ python fetch.py
Successfully retrieved credentials payload:
{'username': 'db_admin', 'password': 'SampleSecurePassword123!', 'host': 'db.internal'}

---

=== Step 5: Lab Teardown & Cost Management ===

AWS Secrets Manager incurs $0.40/secret/month (prorated hourly). To prevent ongoing charges after completing lab tests, force-delete the secret without entering the default recovery retention period:

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

2026-10-05T01:57:01Z

Mflavell: /* Troubleshooting Matrix */

Cybersecurity/AWS Cybersecurity papers/AWS Secrets Example

2026-10-05T01:56:33Z

Mflavell: Created page with "== AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles == === Overview === This guide details the end-to-end setup for creating a secret in AWS Secrets Manager, granting access to an Amazon EC2 instance using an IAM instance profile (eliminating hardcoded credentials), configuring a Python runtime environment on Amazon Linux, and retrieving the secret payload programmatically using boto3. === Architecture & Security Model === * '''AWS Secrets Manager''': St..."

Cybersecurity/AWS Cybersecurity papers

2026-10-05T01:56:13Z

Mflavell:

[[Cybersecurity/AWS Cybersecurity papers/AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles|AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles]]

Cybersecurity/AWS Cybersecurity papers

2026-10-05T01:56:05Z

Mflavell: Created page with "[Cybersecurity/AWS Cybersecurity papers/AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles|AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles]]"

[Cybersecurity/AWS Cybersecurity papers/AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles|AWS Secrets Manager Retrieval on EC2 via IAM Instance Profiles]]

Cybersecurity

2026-10-05T01:54:29Z

Mflavell:

[https://www.cvedetails.com 🔍CVE Search]

[[Vulnerability tree |🌴Vulnerability tree]]

[[Pentesting |✒️Pentesting]]

[[Assessing Risk|😲Risk]]

[[The Dirty Dozen|✈️Dirty dozen]]

[[MTO triangle|📐Motive Technology Opportunity]]

[[North / South & East West Network Security |🧭North/South & East/West Movements]]

[https://cheatsheetseries.owasp.org/index.html 🐝OS Wasp Cheat Sheets]

[[Cyber Kill Chain|⛓️‍💥Cyber Kill Chain]]

[[Cybersecurity/AWS Cybersecurity papers|AWS Cybersecurity papers]]

[https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF Memory Safe Development]

Cybersecurity

2026-10-05T01:53:52Z

Mflavell:

[https://www.cvedetails.com 🔍CVE Search]

[[Vulnerability tree |🌴Vulnerability tree]]

[[Pentesting |✒️Pentesting]]

[[Assessing Risk|😲Risk]]

[[The Dirty Dozen|✈️Dirty dozen]]

[[MTO triangle|📐Motive Technology Opportunity]]

[[North / South & East West Network Security |🧭North/South & East/West Movements]]

[https://cheatsheetseries.owasp.org/index.html 🐝OS Wasp Cheat Sheets]

[[Cyber Kill Chain|⛓️‍💥Cyber Kill Chain]]

[[AWS Cybersecurity papers|AWS Cybersecurity papers]]

[https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF Memory Safe Development]

Computer Notes/Security Services Platform/SSP Intro

2026-09-18T00:04:26Z

Mflavell: Created page with "= Overview = * Runs Vdefend security services * This is an integrated security platform that can be deployed in the cloud. * Services run inside kubanties on virtual machines == Services include == * Security Intelligence * Network Detection and Response * Malware prevention * Rule Analysis = Install process = * Install SSP on vSphere :* Install NSX ::* Link SSP to NSX ::* Upload packages using package management. ::* Install platform features vSphere > SSPI > NSX..."

= Overview =
* Runs Vdefend security services
* This is an integrated security platform that can be deployed in the cloud.
* Services run inside kubanties on virtual machines

== Services include ==

* Security Intelligence
* Network Detection and Response
* Malware prevention
* Rule Analysis

= Install process =

* Install SSP on vSphere
:* Install NSX
::* Link SSP to NSX
::* Upload packages using package management.
::* Install platform features

vSphere > SSPI > NSX > NSX Features
== Package management notes ==
* Accessed from the vdefend SSP Installer
* The URL feature in upload enabled packages to be downloaded to the installer from an internal server on the air gapped network.
::* User downloads package > adds to internal server > downloads from internal server using SSPI
* Packages are signed, only signed packages are allowed.

= Components =
== vSphere ==
* vSphere controls the clusters.
:* By default a cluster has 3 hosts
:* This default is often expanded

* Virtual machines are started on the hosts
:* SSPI and NSX run on their own VM's
:* Other VM's include:
::* Ssp-service-controller
::* SSP-servie-md-0-worker '''two of these'''

This configuration gives a total of 5 VM's and 3 Guest OS in a basic configuration.

== NSX ==
* Management is performed in NSX.
:* After deployment of the NSX connect to the web UI using IP / FQDN

'''Features are based off the configuration you set in NSX:'''

* Security Intelligence
::This feature provides distributed visibility and policy recommendations within an NSX environment, and lets you visualize security posture, analyze traffic flows, and create micro-segmentation policies.

* Network Detection and Response (NDR)
::This feature continuously monitors your network for threats and anomalous behavior, using techniques like network traffic analysis, IDS (Intrusion Detection System), IPS (Intrusion Prevention System), and advanced threat analysis, and then responds to identified threats.

* Malware Prevention Service (MPS)
::This feature provides file-level protection against known and unknown malicious files, including zero-day threats, by analyzing traffic and extracting files for analysis.

*Network Traffic Analysis (NTA)
::This feature monitors and inspects network traffic patterns and identifies anomalies or suspicious behavior.

*Metrics
::This feature collects point-in-time, time-series, and lifetime data to let you perform analyses (such as Top N) of your environment.

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/security-services-platform-overview/key-concepts.html]

=== Private IP Ranges ===
* Defined in security intelligence
* These networks contain unsecured data
* Defining them is a ''must'' for the system to function correctly
[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/overview-of-nsx-intelligence/managing-private-ip-ranges-for-nsx-intelligence.html]

=== Distributed Firewall ===

* This is a firewall that is deployed on each VM.
* Works the same way as a security group in AWS.
* Rules are loaded from NSX with NSX controlling the distributed firewall.

==== Advantages of the distributed firewall approach ====
* Enforces Zero trust
* Prevents lateral movement inside the security boundary (zero trust)
* Parameter security (ie hardware firewalls) are no longer sufficient.
:: If a node is breached no lateral movement is prevented without a ZTA.

* Firewalling each VM is also more secure than an agent based approach.
:: Again this all comes back to zero trust.

A key concept here is [[North / South & East West Network Security]]
==== How it is organized ====

* VM's are assigned to groups.
* Polices contain rules / What to do with the packet.
* Rules are assigned to source and destination groups.

Source Group + Destination group > Policy > Action

* Key point the source group and destination group much match what is defined for the policy.
:* The policy will then execute the action based on the service.
::* The action could be allow / drop / reject

* A policy can be time based.
[https://partnerportal.broadcom.com/documents/d/partner-portal/zero-trust-with-vmware-firewall-pptx?download=true more information on the distributed firewall]

= Gateway Firewall =

This is a parameter firewall with IDS/IPS configured from NSX.

This is a ''software only'' firewall designed to control north / south traffic.
[https://www.vmware.com/docs/vmware-nsx-gateway-firewall]

Manages through NSX manager alongside the distributed firewall.
[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/malware-prevention/getting-started-with-malware-prevention/overview-of-malware-prevention_service.html]

This is installed from the NXT Edge Appliance.
* This is downloaded and installed as an .ova or .iso image. [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-2/installation-guide/installing-nsx-edge/manually-deploying-nsx-edge-node-outside-of-nsx/install-nsx-edge-via-iso-file-as-a-virtual-appliance.html]
* Runs on the vSphere Client [https://www.vmware.com/products/cloud-infrastructure/vsphere]
* Can also be run on bare metal server (using ISO installer) [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-1/installation-guide/installing-nsx-edge/install-nsx-edge-on-bare-metal.html]

== Types of Gateway ==
* Tier-0
:* Connects to external networks
:* Handles routing
:* This is a North/South gateway
:* Controlled by the NSX admin

* Tier-1
:* Handles routing between networks
:* This is a east/west gateway
:* Controlled by tenant admins
[https://vdives.com/2019/10/24/nsx-t-logical-routers-gateways/ More Details]
= SSP Data Storage =
[[SSP Data Storage]]
= External Material =
[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/reference-material.html techdocs]

Computer Notes/Security Services Platform

2026-09-18T00:04:13Z

Mflavell:

Computer Notes/Security Services Platform

2026-09-18T00:03:24Z

Mflavell: Replaced content with "Computer Notes > Security Services Platform Accessing the K8 Cluster Computer Notes/Security Services Platform/EULA bypass"

Computer Notes/Security Services Platform/EULA bypass

2026-09-17T18:51:35Z

Mflavell: Created page with "To bypass the EULA acceptance screen if you get a 500 error: Connect to SSPI and run sudo sqlite3 /config/db/operator_info.db "CREATE UNIQUE INDEX IF NOT EXISTS idx_operator_infos_name ON operator_infos (name);""

To bypass the EULA acceptance screen if you get a 500 error:

Connect to SSPI and run

sudo sqlite3 /config/db/operator_info.db "CREATE UNIQUE INDEX IF NOT EXISTS idx_operator_infos_name ON operator_infos (name);"

Computer Notes/Security Services Platform

2026-09-17T18:50:47Z

Mflavell:

[[Computer Notes]] > Security Services Platform

[[Computer Notes/Security Services Platform/Accessing the K8 Cluster|Accessing the K8 Cluster]]

[[Computer Notes/Security Services Platform/EULA bypass]]

= Overview =

* Runs Vdefend security services

* This is an integrated security platform that can be deployed in the cloud.

* Services run inside kubanties on virtual machines

== Services include ==

* Security Intelligence

* Network Detection and Response

* Malware prevention

* Rule Analysis

= Install process =

* Install SSP on vSphere

:* Install NSX

::* Link SSP to NSX

::* Upload packages using package management.

::* Install platform features

vSphere > SSPI > NSX > NSX Features

== Package management notes ==

* Accessed from the vdefend SSP Installer

* The URL feature in upload enabled packages to be downloaded to the installer from an internal server on the air gapped network.
::* User downloads package > adds to internal server > downloads from internal server using SSPI

* Packages are signed, only signed packages are allowed.

= Components =

== vSphere ==

* vSphere controls the clusters.

:* By default a cluster has 3 hosts

:* This default is often expanded

* Virtual machines are started on the hosts

:* SSPI and NSX run on their own VM's

:* Other VM's include:

::* Ssp-service-controller
::* SSP-servie-md-0-worker '''two of these'''

This configuration gives a total of 5 VM's and 3 Guest OS in a basic configuration.

== NSX ==

* Management is performed in NSX.

:* After deployment of the NSX connect to the web UI using IP / FQDN

'''Features are based off the configuration you set in NSX:'''

* Security Intelligence

::This feature provides distributed visibility and policy recommendations within an NSX environment, and lets you visualize security posture, analyze traffic flows, and create micro-segmentation policies.

* Network Detection and Response (NDR)

::This feature continuously monitors your network for threats and anomalous behavior, using techniques like network traffic analysis, IDS (Intrusion Detection System), IPS (Intrusion Prevention System), and advanced threat analysis, and then responds to identified threats.

* Malware Prevention Service (MPS)

::This feature provides file-level protection against known and unknown malicious files, including zero-day threats, by analyzing traffic and extracting files for analysis.

*Network Traffic Analysis (NTA)

::This feature monitors and inspects network traffic patterns and identifies anomalies or suspicious behavior.

*Metrics

::This feature collects point-in-time, time-series, and lifetime data to let you perform analyses (such as Top N) of your environment.

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/security-services-platform-overview/key-concepts.html]

=== Private IP Ranges ===

* Defined in security intelligence

* These networks contain unsecured data

* Defining them is a ''must'' for the system to function correctly

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/overview-of-nsx-intelligence/managing-private-ip-ranges-for-nsx-intelligence.html]

=== Distributed Firewall ===

* This is a firewall that is deployed on each VM.

* Works the same way as a security group in AWS.

* Rules are loaded from NSX with NSX controlling the distributed firewall.

==== Advantages of the distributed firewall approach ====

* Enforces Zero trust

* Prevents lateral movement inside the security boundary (zero trust)

* Parameter security (ie hardware firewalls) are no longer sufficient.

:: If a node is breached no lateral movement is prevented without a ZTA.

* Firewalling each VM is also more secure than an agent based approach.

:: Again this all comes back to zero trust.

A key concept here is [[North / South & East West Network Security]]

==== How it is organized ====

* VM's are assigned to groups.

* Polices contain rules / What to do with the packet.

* Rules are assigned to source and destination groups.

Source Group + Destination group > Policy > Action

* Key point the source group and destination group much match what is defined for the policy.

:* The policy will then execute the action based on the service.

::* The action could be allow / drop / reject

* A policy can be time based.

[https://partnerportal.broadcom.com/documents/d/partner-portal/zero-trust-with-vmware-firewall-pptx?download=true more information on the distributed firewall]

= Gateway Firewall =

This is a parameter firewall with IDS/IPS configured from NSX.

This is a ''software only'' firewall designed to control north / south traffic.
[https://www.vmware.com/docs/vmware-nsx-gateway-firewall]

Manages through NSX manager alongside the distributed firewall.
[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/malware-prevention/getting-started-with-malware-prevention/overview-of-malware-prevention_service.html]

This is installed from the NXT Edge Appliance.

* This is downloaded and installed as an .ova or .iso image. [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-2/installation-guide/installing-nsx-edge/manually-deploying-nsx-edge-node-outside-of-nsx/install-nsx-edge-via-iso-file-as-a-virtual-appliance.html]

* Runs on the vSphere Client [https://www.vmware.com/products/cloud-infrastructure/vsphere]

* Can also be run on bare metal server (using ISO installer) [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-1/installation-guide/installing-nsx-edge/install-nsx-edge-on-bare-metal.html]

== Types of Gateway ==

* Tier-0
:* Connects to external networks
:* Handles routing
:* This is a North/South gateway
:* Controlled by the NSX admin

* Tier-1
:* Handles routing between networks
:* This is a east/west gateway
:* Controlled by tenant admins

[https://vdives.com/2019/10/24/nsx-t-logical-routers-gateways/ More Details]

= SSP Data Storage =
[[SSP Data Storage]]

= External Material =

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/reference-material.html techdocs]

Computer Notes/Security Services Platform

2026-09-17T18:50:03Z

Mflavell:

[[Computer Notes]] > Security Services Platform

[[Computer Notes/Security Services Platform/Accessing the K8 Cluster|Accessing the K8 Cluster]]

[[Computer Notes/Security Services Platform/ELUA bypass]]

= Overview =

* Runs Vdefend security services

* This is an integrated security platform that can be deployed in the cloud.

* Services run inside kubanties on virtual machines

== Services include ==

* Security Intelligence

* Network Detection and Response

* Malware prevention

* Rule Analysis

= Install process =

* Install SSP on vSphere

:* Install NSX

::* Link SSP to NSX

::* Upload packages using package management.

::* Install platform features

vSphere > SSPI > NSX > NSX Features

== Package management notes ==

* Accessed from the vdefend SSP Installer

* The URL feature in upload enabled packages to be downloaded to the installer from an internal server on the air gapped network.
::* User downloads package > adds to internal server > downloads from internal server using SSPI

* Packages are signed, only signed packages are allowed.

= Components =

== vSphere ==

* vSphere controls the clusters.

:* By default a cluster has 3 hosts

:* This default is often expanded

* Virtual machines are started on the hosts

:* SSPI and NSX run on their own VM's

:* Other VM's include:

::* Ssp-service-controller
::* SSP-servie-md-0-worker '''two of these'''

This configuration gives a total of 5 VM's and 3 Guest OS in a basic configuration.

== NSX ==

* Management is performed in NSX.

:* After deployment of the NSX connect to the web UI using IP / FQDN

'''Features are based off the configuration you set in NSX:'''

* Security Intelligence

::This feature provides distributed visibility and policy recommendations within an NSX environment, and lets you visualize security posture, analyze traffic flows, and create micro-segmentation policies.

* Network Detection and Response (NDR)

::This feature continuously monitors your network for threats and anomalous behavior, using techniques like network traffic analysis, IDS (Intrusion Detection System), IPS (Intrusion Prevention System), and advanced threat analysis, and then responds to identified threats.

* Malware Prevention Service (MPS)

::This feature provides file-level protection against known and unknown malicious files, including zero-day threats, by analyzing traffic and extracting files for analysis.

*Network Traffic Analysis (NTA)

::This feature monitors and inspects network traffic patterns and identifies anomalies or suspicious behavior.

*Metrics

::This feature collects point-in-time, time-series, and lifetime data to let you perform analyses (such as Top N) of your environment.

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/security-services-platform-overview/key-concepts.html]

=== Private IP Ranges ===

* Defined in security intelligence

* These networks contain unsecured data

* Defining them is a ''must'' for the system to function correctly

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/overview-of-nsx-intelligence/managing-private-ip-ranges-for-nsx-intelligence.html]

=== Distributed Firewall ===

* This is a firewall that is deployed on each VM.

* Works the same way as a security group in AWS.

* Rules are loaded from NSX with NSX controlling the distributed firewall.

==== Advantages of the distributed firewall approach ====

* Enforces Zero trust

* Prevents lateral movement inside the security boundary (zero trust)

* Parameter security (ie hardware firewalls) are no longer sufficient.

:: If a node is breached no lateral movement is prevented without a ZTA.

* Firewalling each VM is also more secure than an agent based approach.

:: Again this all comes back to zero trust.

A key concept here is [[North / South & East West Network Security]]

==== How it is organized ====

* VM's are assigned to groups.

* Polices contain rules / What to do with the packet.

* Rules are assigned to source and destination groups.

Source Group + Destination group > Policy > Action

* Key point the source group and destination group much match what is defined for the policy.

:* The policy will then execute the action based on the service.

::* The action could be allow / drop / reject

* A policy can be time based.

[https://partnerportal.broadcom.com/documents/d/partner-portal/zero-trust-with-vmware-firewall-pptx?download=true more information on the distributed firewall]

= Gateway Firewall =

This is a parameter firewall with IDS/IPS configured from NSX.

This is a ''software only'' firewall designed to control north / south traffic.
[https://www.vmware.com/docs/vmware-nsx-gateway-firewall]

Manages through NSX manager alongside the distributed firewall.
[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/malware-prevention/getting-started-with-malware-prevention/overview-of-malware-prevention_service.html]

This is installed from the NXT Edge Appliance.

* This is downloaded and installed as an .ova or .iso image. [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-2/installation-guide/installing-nsx-edge/manually-deploying-nsx-edge-node-outside-of-nsx/install-nsx-edge-via-iso-file-as-a-virtual-appliance.html]

* Runs on the vSphere Client [https://www.vmware.com/products/cloud-infrastructure/vsphere]

* Can also be run on bare metal server (using ISO installer) [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-1/installation-guide/installing-nsx-edge/install-nsx-edge-on-bare-metal.html]

== Types of Gateway ==

* Tier-0
:* Connects to external networks
:* Handles routing
:* This is a North/South gateway
:* Controlled by the NSX admin

* Tier-1
:* Handles routing between networks
:* This is a east/west gateway
:* Controlled by tenant admins

[https://vdives.com/2019/10/24/nsx-t-logical-routers-gateways/ More Details]

= SSP Data Storage =
[[SSP Data Storage]]

= External Material =

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/reference-material.html techdocs]

Computer Notes/Security Services Platform

2026-09-17T18:49:53Z

Mflavell:

[[Computer Notes]] > Security Services Platform

[[Computer Notes/Security Services Platform/Accessing the K8 Cluster|Accessing the K8 Cluster]]

[[[Computer Notes/Security Services Platform/ELUA bypass]]

= Overview =

* Runs Vdefend security services

* This is an integrated security platform that can be deployed in the cloud.

* Services run inside kubanties on virtual machines

== Services include ==

* Security Intelligence

* Network Detection and Response

* Malware prevention

* Rule Analysis

= Install process =

* Install SSP on vSphere

:* Install NSX

::* Link SSP to NSX

::* Upload packages using package management.

::* Install platform features

vSphere > SSPI > NSX > NSX Features

== Package management notes ==

* Accessed from the vdefend SSP Installer

* The URL feature in upload enabled packages to be downloaded to the installer from an internal server on the air gapped network.
::* User downloads package > adds to internal server > downloads from internal server using SSPI

* Packages are signed, only signed packages are allowed.

= Components =

== vSphere ==

* vSphere controls the clusters.

:* By default a cluster has 3 hosts

:* This default is often expanded

* Virtual machines are started on the hosts

:* SSPI and NSX run on their own VM's

:* Other VM's include:

::* Ssp-service-controller
::* SSP-servie-md-0-worker '''two of these'''

This configuration gives a total of 5 VM's and 3 Guest OS in a basic configuration.

== NSX ==

* Management is performed in NSX.

:* After deployment of the NSX connect to the web UI using IP / FQDN

'''Features are based off the configuration you set in NSX:'''

* Security Intelligence

::This feature provides distributed visibility and policy recommendations within an NSX environment, and lets you visualize security posture, analyze traffic flows, and create micro-segmentation policies.

* Network Detection and Response (NDR)

::This feature continuously monitors your network for threats and anomalous behavior, using techniques like network traffic analysis, IDS (Intrusion Detection System), IPS (Intrusion Prevention System), and advanced threat analysis, and then responds to identified threats.

* Malware Prevention Service (MPS)

::This feature provides file-level protection against known and unknown malicious files, including zero-day threats, by analyzing traffic and extracting files for analysis.

*Network Traffic Analysis (NTA)

::This feature monitors and inspects network traffic patterns and identifies anomalies or suspicious behavior.

*Metrics

::This feature collects point-in-time, time-series, and lifetime data to let you perform analyses (such as Top N) of your environment.

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/security-services-platform-overview/key-concepts.html]

=== Private IP Ranges ===

* Defined in security intelligence

* These networks contain unsecured data

* Defining them is a ''must'' for the system to function correctly

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/overview-of-nsx-intelligence/managing-private-ip-ranges-for-nsx-intelligence.html]

=== Distributed Firewall ===

* This is a firewall that is deployed on each VM.

* Works the same way as a security group in AWS.

* Rules are loaded from NSX with NSX controlling the distributed firewall.

==== Advantages of the distributed firewall approach ====

* Enforces Zero trust

* Prevents lateral movement inside the security boundary (zero trust)

* Parameter security (ie hardware firewalls) are no longer sufficient.

:: If a node is breached no lateral movement is prevented without a ZTA.

* Firewalling each VM is also more secure than an agent based approach.

:: Again this all comes back to zero trust.

A key concept here is [[North / South & East West Network Security]]

==== How it is organized ====

* VM's are assigned to groups.

* Polices contain rules / What to do with the packet.

* Rules are assigned to source and destination groups.

Source Group + Destination group > Policy > Action

* Key point the source group and destination group much match what is defined for the policy.

:* The policy will then execute the action based on the service.

::* The action could be allow / drop / reject

* A policy can be time based.

[https://partnerportal.broadcom.com/documents/d/partner-portal/zero-trust-with-vmware-firewall-pptx?download=true more information on the distributed firewall]

= Gateway Firewall =

This is a parameter firewall with IDS/IPS configured from NSX.

This is a ''software only'' firewall designed to control north / south traffic.
[https://www.vmware.com/docs/vmware-nsx-gateway-firewall]

Manages through NSX manager alongside the distributed firewall.
[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/malware-prevention/getting-started-with-malware-prevention/overview-of-malware-prevention_service.html]

This is installed from the NXT Edge Appliance.

* This is downloaded and installed as an .ova or .iso image. [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-2/installation-guide/installing-nsx-edge/manually-deploying-nsx-edge-node-outside-of-nsx/install-nsx-edge-via-iso-file-as-a-virtual-appliance.html]

* Runs on the vSphere Client [https://www.vmware.com/products/cloud-infrastructure/vsphere]

* Can also be run on bare metal server (using ISO installer) [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-1/installation-guide/installing-nsx-edge/install-nsx-edge-on-bare-metal.html]

== Types of Gateway ==

* Tier-0
:* Connects to external networks
:* Handles routing
:* This is a North/South gateway
:* Controlled by the NSX admin

* Tier-1
:* Handles routing between networks
:* This is a east/west gateway
:* Controlled by tenant admins

[https://vdives.com/2019/10/24/nsx-t-logical-routers-gateways/ More Details]

= SSP Data Storage =
[[SSP Data Storage]]

= External Material =

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/reference-material.html techdocs]

Computer Notes/Security Services Platform/Accessing the K8 Cluster

2026-09-11T18:00:49Z

Mflavell:

'''Accessing Security Services Platform (SSP) Kubernetes Cluster Nodes from SSPI using Key Pair Authentication''' is a operational procedure used by system administrators to establish secure, passwordless SSH sessions between a VMware Security Services Platform Installer (SSPI) appliance and its managed Kubernetes (K8s) cluster nodes.

Utilizing public-key cryptography eliminates the reliance on static passwords, simplifies automated node administration, and aligns with security best practices for infrastructure management.

== Prerequisites ==

Before configuring key pair authentication, ensure the following requirements are met:
* Administrative shell access (`sysadmin` or `root`) to the deployment SSPI appliance.
* Operational access to the `kubectl` command-line utility configured on the SSPI host.
* Network connectivity on TCP port 22 (SSH) between the SSPI appliance and all target Kubernetes nodes (Control Plane and Worker nodes).

== Step 1: Generate an SSH Key Pair on SSPI ==

If an SSH key pair does not already exist on the SSPI appliance, generate a high-entropy key pair (such as Ed25519) from the SSPI terminal shell.

# Log into the SSPI host via SSH:
#: <code>ssh sysadmin@<SSPI_IP_ADDRESS></code>
# Switch to the root account if required for system-level node administration:
#: <code>sudo -i</code>
# Generate a new Ed25519 key pair:
#: <code>ssh-keygen -t ed25519 -C "sspi-k8s-admin"</code>
# Press ENTER to accept the default file location (<code>~/.ssh/id_ed25519</code>).
# Optionally enter a passphrase to secure the private key on disk.

== Step 2: Retrieve Target Kubernetes Node IP Addresses ==

Query the Kubernetes API server from the SSPI command line to identify the internal IP addresses of the cluster nodes:

<code>kubectl get nodes -o wide</code>

Note the values in the <code>INTERNAL-IP</code> column for the target Control Plane or Worker nodes.

== Step 3: Distribute the Public Key to Cluster Nodes ==

To establish trust, copy the generated public key (<code>id_ed25519.pub</code>) to the <code>~/.ssh/authorized_keys</code> file on the target node.

=== Method A: Using <code>ssh-copy-id</code> (Automated) ===
If password authentication is temporarily enabled on the nodes, run:

<code>ssh-copy-id -i ~/.ssh/id_ed25519.pub sysadmin@<NODE_INTERNAL_IP></code>

Enter the node's password when prompted to append the key automatically.

=== Method B: Manual Injection (Pre-deployment or Cluster Spec) ===
If direct password access to the nodes is disabled, inject the public key content directly into the cluster specification or pre-seed file during initial provision:

# Display the public key:
#: <code>cat ~/.ssh/id_ed25519.pub</code>
# Copy the string output and append it to <code>/root/.ssh/authorized_keys</code> on the target node file system.
# Ensure correct file permissions on the target node:
#: <code>chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys</code>

== Step 4: Establish Passwordless SSH Connection ==

Verify the key pair authentication setup by opening a new SSH connection from the SSPI appliance to the target node:

<code>ssh -i ~/.ssh/id_ed25519 sysadmin@<NODE_INTERNAL_IP></code>

Upon successful authentication, the terminal prompt will update to reflect the target node's hostname without prompting for a password.

== Security Best Practices ==

* '''Restrict Root File Permissions:''' Verify that the private key on the SSPI appliance maintains strict permissions (<code>chmod 600 ~/.ssh/id_ed25519</code>) to prevent unauthorized read access by non-privileged local users.
* '''Audit Authorized Keys:''' Periodically audit the <code>/root/.ssh/authorized_keys</code> file on cluster nodes to remove obsolete or unauthorized public keys.
* '''Least Privilege:''' Limit direct node SSH access to emergency troubleshooting and diagnostic operations. Standard cluster administrative operations should be performed via `kubectl` or API endpoints.

== Troubleshooting ==

=== Permission Denied (publickey) ===
If connection fails with a <code>Permission denied (publickey)</code> error:
* Verify key permissions on the SSPI host: <code>chmod 600 ~/.ssh/id_ed25519</code>.
* Check remote permissions on the node: <code>chmod 700 /root/.ssh</code> and <code>chmod 600 /root/.ssh/authorized_keys</code>.
* Verbose SSH output can be reviewed by appending <code>-vvv</code> to the SSH command:
*: <code>ssh -vvv -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>

== See Also ==

[[Category:Kubernetes]]
[[Category:System Administration]]
[[Category:VMware]]
[[Category:Network Security]]

Computer Notes/Kubernetes/Kubernetes Command-Line Cheat Sheet

2026-09-10T00:14:12Z

Mflavell: Created page with "'''Kubernetes Command-Line Cheat Sheet''' is a reference guide for standard operations using the <code>kubectl</code> command-line interface to manage Kubernetes clusters, workloads, and node infrastructure. == Cluster Context & Namespaces == {| class="wikitable" ! Command !! Description |- | <code>kubectl config get-contexts</code> || List all available cluster contexts. |- | <code>kubectl config use-context <context-name></code> || Switch active cluster context...."

'''Kubernetes Command-Line Cheat Sheet''' is a reference guide for standard operations using the <code>kubectl</code> command-line interface to manage Kubernetes clusters, workloads, and node infrastructure.

== Cluster Context & Namespaces ==
{| class="wikitable"
! Command !! Description
|-
| <code>kubectl config get-contexts</code> || List all available cluster contexts.
|-
| <code>kubectl config use-context <context-name></code> || Switch active cluster context.
|-
| <code>kubectl config set-context --current --namespace=<ns></code> || Set default namespace for current context.
|-
| <code>kubectl get ns</code> || List all namespaces in the cluster.
|}

== Viewing & Inspecting Resources ==
{| class="wikitable"
! Command !! Description
|-
| <code>kubectl get pods -A</code> || List all pods across all namespaces.
|-
| <code>kubectl get pods -o wide</code> || List pods with IP addresses and node assignments.
|-
| <code>kubectl get all -n <namespace></code> || Show all active resources in a specific namespace.
|-
| <code>kubectl describe <resource>/<name></code> || View detailed state, events, and configuration.
|-
| <code>kubectl get <resource> <name> -o yaml</code> || Export resource manifest to YAML format.
|}

== Deploying & Managing Workloads ==
{| class="wikitable"
! Command !! Description
|-
| <code>kubectl apply -f <file.yaml></code> || Create or update resources declaratively.
|-
| <code>kubectl delete -f <file.yaml></code> || Delete resources defined in a YAML manifest.
|-
| <code>kubectl scale deploy/<name> --replicas=<N></code> || Scale the replica count of a Deployment.
|-
| <code>kubectl rollout restart deploy/<name></code> || Perform a zero-downtime rolling restart.
|-
| <code>kubectl rollout undo deploy/<name></code> || Roll back to the previous deployment revision.
|}

== Debugging & Observability ==
{| class="wikitable"
! Command !! Description
|-
| <code>kubectl logs -f <pod-name></code> || Stream real-time logs from a pod container.
|-
| <code>kubectl logs -p <pod-name></code> || View logs from a previous crashed container instance.
|-
| <code>kubectl exec -it <pod-name> -- /bin/sh</code> || Open an interactive shell inside a running pod.
|-
| <code>kubectl port-forward svc/<name> 8080:80</code> || Forward local port 8080 to cluster service port 80.
|-
| <code>kubectl get events --sort-by='.metadata.creationTimestamp'</code> || List recent cluster events sorted by timestamp.
|-
| <code>kubectl top pods</code> / <code>kubectl top nodes</code> || Display live CPU and memory metrics.
|}

== Node Operations & Maintenance ==
{| class="wikitable"
! Command !! Description
|-
| <code>kubectl get nodes</code> || List all cluster nodes and their current status.
|-
| <code>kubectl cordon <node-name></code> || Mark a node as unschedulable.
|-
| <code>kubectl drain <node-name> --ignore-daemonsets</code> || Safely evict all pods before node maintenance.
|-
| <code>kubectl uncordon <node-name></code> || Mark a node as schedulable again.
|}

== Essential Productivity Shell Shortcuts ==
Add these shortcuts to your shell profile (<code>~/.bashrc</code> or <code>~/.zshrc</code>) to speed up workflow:

<syntaxhighlight lang="bash">
alias k='kubectl'
alias kgp='kubectl get pods'
alias kgs='kubectl get svc'
alias kgd='kubectl get deployments'
alias kdp='kubectl describe pod'
alias kl='kubectl logs -f'
</syntaxhighlight>

== See Also ==
* [[Kubernetes]]
* [[Secure Shell]]

[[Category:Kubernetes]]
[[Category:Cheat Sheets]]
[[Category:System Administration]]

Computer Notes/Kubernetes

2026-09-10T00:13:56Z

Mflavell:

[[Computer Notes/Kubernetes/Kubernetes Command-Line Cheat Sheet|Kubernetes Command-Line Cheat Sheet]]

Computer Notes/Kubernetes

2026-09-10T00:13:25Z

Mflavell: Created page with "Kubernetes Command-Line Cheat Sheet"

[[Computer Notes/Kubernetes|Kubernetes Command-Line Cheat Sheet]]

Computer Notes

2026-09-10T00:12:52Z

Mflavell:

Computer Notes/Security Services Platform/Accessing the K8 Cluster

2026-09-10T00:05:38Z

Mflavell: /* Step 1: Generate an SSH Key Pair on SSPI */

'''Accessing Security Services Platform (SSP) Kubernetes Cluster Nodes from SSPI using Key Pair Authentication''' is a operational procedure used by system administrators to establish secure, passwordless SSH sessions between a VMware Security Services Platform Installer (SSPI) appliance and its managed Kubernetes (K8s) cluster nodes.

Utilizing public-key cryptography eliminates the reliance on static passwords, simplifies automated node administration, and aligns with security best practices for infrastructure management.

== Prerequisites ==

Before configuring key pair authentication, ensure the following requirements are met:
* Administrative shell access (`sysadmin` or `root`) to the deployment SSPI appliance.
* Operational access to the `kubectl` command-line utility configured on the SSPI host.
* Network connectivity on TCP port 22 (SSH) between the SSPI appliance and all target Kubernetes nodes (Control Plane and Worker nodes).

== Step 1: Generate an SSH Key Pair on SSPI ==

If an SSH key pair does not already exist on the SSPI appliance, generate a high-entropy key pair (such as Ed25519) from the SSPI terminal shell.

# Log into the SSPI host via SSH:
#: <code>ssh sysadmin@<SSPI_IP_ADDRESS></code>
# Switch to the root account if required for system-level node administration:
#: <code>sudo -i</code>
# Generate a new Ed25519 key pair:
#: <code>ssh-keygen -t ed25519 -C "sspi-k8s-admin"</code>
# Press ENTER to accept the default file location (<code>~/.ssh/id_ed25519</code>).
# Optionally enter a passphrase to secure the private key on disk.

== Step 2: Retrieve Target Kubernetes Node IP Addresses ==

Query the Kubernetes API server from the SSPI command line to identify the internal IP addresses of the cluster nodes:

<code>kubectl get nodes -o wide</code>

Note the values in the <code>INTERNAL-IP</code> column for the target Control Plane or Worker nodes.

== Step 3: Distribute the Public Key to Cluster Nodes ==

To establish trust, copy the generated public key (<code>id_ed25519.pub</code>) to the <code>~/.ssh/authorized_keys</code> file on the target node.

=== Method A: Using <code>ssh-copy-id</code> (Automated) ===
If password authentication is temporarily enabled on the nodes, run:

<code>ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<NODE_INTERNAL_IP></code>

Enter the node's password when prompted to append the key automatically.

=== Method B: Manual Injection (Pre-deployment or Cluster Spec) ===
If direct password access to the nodes is disabled, inject the public key content directly into the cluster specification or pre-seed file during initial provision:

# Display the public key:
#: <code>cat ~/.ssh/id_ed25519.pub</code>
# Copy the string output and append it to <code>/root/.ssh/authorized_keys</code> on the target node file system.
# Ensure correct file permissions on the target node:
#: <code>chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys</code>

== Step 4: Establish Passwordless SSH Connection ==

Verify the key pair authentication setup by opening a new SSH connection from the SSPI appliance to the target node:

<code>ssh -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>

Upon successful authentication, the terminal prompt will update to reflect the target node's hostname without prompting for a password.

== Security Best Practices ==

* '''Restrict Root File Permissions:''' Verify that the private key on the SSPI appliance maintains strict permissions (<code>chmod 600 ~/.ssh/id_ed25519</code>) to prevent unauthorized read access by non-privileged local users.
* '''Audit Authorized Keys:''' Periodically audit the <code>/root/.ssh/authorized_keys</code> file on cluster nodes to remove obsolete or unauthorized public keys.
* '''Least Privilege:''' Limit direct node SSH access to emergency troubleshooting and diagnostic operations. Standard cluster administrative operations should be performed via `kubectl` or API endpoints.

== Troubleshooting ==

=== Permission Denied (publickey) ===
If connection fails with a <code>Permission denied (publickey)</code> error:
* Verify key permissions on the SSPI host: <code>chmod 600 ~/.ssh/id_ed25519</code>.
* Check remote permissions on the node: <code>chmod 700 /root/.ssh</code> and <code>chmod 600 /root/.ssh/authorized_keys</code>.
* Verbose SSH output can be reviewed by appending <code>-vvv</code> to the SSH command:
*: <code>ssh -vvv -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>

== See Also ==

[[Category:Kubernetes]]
[[Category:System Administration]]
[[Category:VMware]]
[[Category:Network Security]]

Computer Notes/Security Services Platform/Accessing the K8 Cluster

2026-09-10T00:04:39Z

Mflavell:

'''Accessing Security Services Platform (SSP) Kubernetes Cluster Nodes from SSPI using Key Pair Authentication''' is a operational procedure used by system administrators to establish secure, passwordless SSH sessions between a VMware Security Services Platform Installer (SSPI) appliance and its managed Kubernetes (K8s) cluster nodes.

Utilizing public-key cryptography eliminates the reliance on static passwords, simplifies automated node administration, and aligns with security best practices for infrastructure management.

== Prerequisites ==

Before configuring key pair authentication, ensure the following requirements are met:
* Administrative shell access (`sysadmin` or `root`) to the deployment SSPI appliance.
* Operational access to the `kubectl` command-line utility configured on the SSPI host.
* Network connectivity on TCP port 22 (SSH) between the SSPI appliance and all target Kubernetes nodes (Control Plane and Worker nodes).

== Step 1: Generate an SSH Key Pair on SSPI ==

If an SSH key pair does not already exist on the SSPI appliance, generate a high-entropy key pair (such as Ed25519) from the SSPI terminal shell.

# Log into the SSPI host via SSH:
#: <code>ssh sysadmin@<SSPI_IP_ADDRESS></code>
# Switch to the root account if required for system-level node administration:
#: <code>sudo -i</code>
# Generate a new Ed25519 key pair:
#: <code>ssh-keygen -t ed25519 -C "sspi-k8s-admin"</code>
# Press {{Key|Enter}} to accept the default file location (<code>~/.ssh/id_ed25519</code>).
# Optionally enter a passphrase to secure the private key on disk.

== Step 2: Retrieve Target Kubernetes Node IP Addresses ==

Query the Kubernetes API server from the SSPI command line to identify the internal IP addresses of the cluster nodes:

<code>kubectl get nodes -o wide</code>

Note the values in the <code>INTERNAL-IP</code> column for the target Control Plane or Worker nodes.

== Step 3: Distribute the Public Key to Cluster Nodes ==

To establish trust, copy the generated public key (<code>id_ed25519.pub</code>) to the <code>~/.ssh/authorized_keys</code> file on the target node.

=== Method A: Using <code>ssh-copy-id</code> (Automated) ===
If password authentication is temporarily enabled on the nodes, run:

<code>ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<NODE_INTERNAL_IP></code>

Enter the node's password when prompted to append the key automatically.

=== Method B: Manual Injection (Pre-deployment or Cluster Spec) ===
If direct password access to the nodes is disabled, inject the public key content directly into the cluster specification or pre-seed file during initial provision:

# Display the public key:
#: <code>cat ~/.ssh/id_ed25519.pub</code>
# Copy the string output and append it to <code>/root/.ssh/authorized_keys</code> on the target node file system.
# Ensure correct file permissions on the target node:
#: <code>chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys</code>

== Step 4: Establish Passwordless SSH Connection ==

Verify the key pair authentication setup by opening a new SSH connection from the SSPI appliance to the target node:

<code>ssh -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>

Upon successful authentication, the terminal prompt will update to reflect the target node's hostname without prompting for a password.

== Security Best Practices ==

* '''Restrict Root File Permissions:''' Verify that the private key on the SSPI appliance maintains strict permissions (<code>chmod 600 ~/.ssh/id_ed25519</code>) to prevent unauthorized read access by non-privileged local users.
* '''Audit Authorized Keys:''' Periodically audit the <code>/root/.ssh/authorized_keys</code> file on cluster nodes to remove obsolete or unauthorized public keys.
* '''Least Privilege:''' Limit direct node SSH access to emergency troubleshooting and diagnostic operations. Standard cluster administrative operations should be performed via `kubectl` or API endpoints.

== Troubleshooting ==

=== Permission Denied (publickey) ===
If connection fails with a <code>Permission denied (publickey)</code> error:
* Verify key permissions on the SSPI host: <code>chmod 600 ~/.ssh/id_ed25519</code>.
* Check remote permissions on the node: <code>chmod 700 /root/.ssh</code> and <code>chmod 600 /root/.ssh/authorized_keys</code>.
* Verbose SSH output can be reviewed by appending <code>-vvv</code> to the SSH command:
*: <code>ssh -vvv -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>

== See Also ==

[[Category:Kubernetes]]
[[Category:System Administration]]
[[Category:VMware]]
[[Category:Network Security]]

Computer Notes/Security Services Platform/Accessing the K8 Cluster

2026-09-10T00:03:49Z

Mflavell:

'''Accessing Security Services Platform (SSP) Kubernetes Cluster Nodes from SSPI using Key Pair Authentication''' is a operational procedure used by system administrators to establish secure, passwordless SSH sessions between a VMware Security Services Platform Installer (SSPI) appliance and its managed Kubernetes (K8s) cluster nodes.

Utilizing public-key cryptography eliminates the reliance on static passwords, simplifies automated node administration, and aligns with security best practices for infrastructure management.

== Prerequisites ==

Before configuring key pair authentication, ensure the following requirements are met:
* Administrative shell access (`sysadmin` or `root`) to the deployment SSPI appliance.
* Operational access to the `kubectl` command-line utility configured on the SSPI host.
* Network connectivity on TCP port 22 (SSH) between the SSPI appliance and all target Kubernetes nodes (Control Plane and Worker nodes).

== Step 1: Generate an SSH Key Pair on SSPI ==

If an SSH key pair does not already exist on the SSPI appliance, generate a high-entropy key pair (such as Ed25519) from the SSPI terminal shell.

# Log into the SSPI host via SSH:
#: <code>ssh sysadmin@<SSPI_IP_ADDRESS></code>
# Switch to the root account if required for system-level node administration:
#: <code>sudo -i</code>
# Generate a new Ed25519 key pair:
#: <code>ssh-keygen -t ed25519 -C "sspi-k8s-admin"</code>
# Press {{Key|Enter}} to accept the default file location (<code>~/.ssh/id_ed25519</code>).
# Optionally enter a passphrase to secure the private key on disk.

== Step 2: Retrieve Target Kubernetes Node IP Addresses ==

Query the Kubernetes API server from the SSPI command line to identify the internal IP addresses of the cluster nodes:

<code>kubectl get nodes -o wide</code>

Note the values in the <code>INTERNAL-IP</code> column for the target Control Plane or Worker nodes.

== Step 3: Distribute the Public Key to Cluster Nodes ==

To establish trust, copy the generated public key (<code>id_ed25519.pub</code>) to the <code>~/.ssh/authorized_keys</code> file on the target node.

=== Method A: Using <code>ssh-copy-id</code> (Automated) ===
If password authentication is temporarily enabled on the nodes, run:

<code>ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<NODE_INTERNAL_IP></code>

Enter the node's password when prompted to append the key automatically.

=== Method B: Manual Injection (Pre-deployment or Cluster Spec) ===
If direct password access to the nodes is disabled, inject the public key content directly into the cluster specification or pre-seed file during initial provision:

# Display the public key:
#: <code>cat ~/.ssh/id_ed25519.pub</code>
# Copy the string output and append it to <code>/root/.ssh/authorized_keys</code> on the target node file system.
# Ensure correct file permissions on the target node:
#: <code>chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys</code>

== Step 4: Establish Passwordless SSH Connection ==

Verify the key pair authentication setup by opening a new SSH connection from the SSPI appliance to the target node:

<code>ssh -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>

Upon successful authentication, the terminal prompt will update to reflect the target node's hostname without prompting for a password.

== Security Best Practices ==

* '''Restrict Root File Permissions:''' Verify that the private key on the SSPI appliance maintains strict permissions (<code>chmod 600 ~/.ssh/id_ed25519</code>) to prevent unauthorized read access by non-privileged local users.
* '''Audit Authorized Keys:''' Periodically audit the <code>/root/.ssh/authorized_keys</code> file on cluster nodes to remove obsolete or unauthorized public keys.
* '''Least Privilege:''' Limit direct node SSH access to emergency troubleshooting and diagnostic operations. Standard cluster administrative operations should be performed via `kubectl` or API endpoints.

== Troubleshooting ==

=== Permission Denied (publickey) ===
If connection fails with a <code>Permission denied (publickey)</code> error:
* Verify key permissions on the SSPI host: <code>chmod 600 ~/.ssh/id_ed25519</code>.
* Check remote permissions on the node: <code>chmod 700 /root/.ssh</code> and <code>chmod 600 /root/.ssh/authorized_keys</code>.
* Verbose SSH output can be reviewed by appending <code>-vvv</code> to the SSH command:
*: <code>ssh -vvv -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>

== See Also ==
* [[Secure Shell]]
* [[Kubernetes]]
* [[Public-key cryptography]]
* [[ssh-keygen]]

[[Category:Kubernetes]]
[[Category:System Administration]]
[[Category:VMware]]
[[Category:Network Security]]

Computer Notes/Security Services Platform/Accessing the K8 Cluster

2026-09-10T00:02:35Z

Mflavell: Created page with "'''SSH key pair authentication''' is a public-key cryptographic mechanism used within the Secure Shell (SSH) protocol to authenticate users or machines attempting to establish a remote network connection. Unlike traditional password-based authentication, key pair authentication relies on asymmetric cryptography, utilizing a mathematically linked pair of cryptographic keys: a '''public key''' and a '''private key'''. == Mechanism and Architecture == SSH key authenticatio..."

'''SSH key pair authentication''' is a public-key cryptographic mechanism used within the Secure Shell (SSH) protocol to authenticate users or machines attempting to establish a remote network connection. Unlike traditional password-based authentication, key pair authentication relies on asymmetric cryptography, utilizing a mathematically linked pair of cryptographic keys: a '''public key''' and a '''private key'''.

== Mechanism and Architecture ==
SSH key authentication operates on a challenge-response model designed to verify identity without ever transmitting sensitive credential data over the network.

* '''Private Key:''' Kept strictly confidential on the client machine. It is protected by local file permissions (typically <code>chmod 600</code>) and can be further secured using a passphrase.
* '''Public Key:''' Placed on the target server, where it is stored in the remote user's configuration file (commonly <code>~/.ssh/authorized_keys</code>).

When a client requests an SSH session:
# The client sends a signal to the server identifying the public key it wishes to use for authentication.
# The server checks its <code>authorized_keys</code> file to confirm the key is authorized for the requested account.
# The server generates a cryptographic challenge (a random string of data) and sends it to the client.
# The client uses its local private key to sign the challenge, generating a digital signature, which is sent back to the server.
# The server uses the stored public key to verify the signature. If valid, the session is established.

== Common Algorithms and Key Generation ==
Key pairs are generated using software utilities such as OpenSSH's <code>ssh-keygen</code>. The security and performance of the key pair depend on the underlying mathematical algorithm:

* '''Ed25519:''' An Elliptic Curve Digital Signature Algorithm (EdDSA) scheme offering high performance, immunity to side-channel attacks, and a fixed key length of 256 bits. It is widely considered the modern standard.
* '''ECDSA:''' An elliptic curve implementation based on NIST curves. While secure, implementation flaws in random number generation can compromise private keys.
* '''RSA:''' A historical standard based on the integer factorization problem. Modern security guidelines mandate key lengths of 3072 or 4096 bits, as shorter lengths (e.g., 2048-bit) are increasingly vulnerable to advancing computational power.

== Advantages and Applications ==
SSH key pair authentication offers significant operational benefits over standard passwords:

* '''Mitigation of Brute-Force Attacks:''' Modern SSH keys possess high entropy, rendering dictionary and online brute-force attacks mathematically infeasible.
* '''Non-Interactive Automation:''' Keys facilitate secure, automated execution of administrative scripts, deployment pipelines (CI/CD), and infrastructure management tools without human intervention.
* '''Granular Access Control:''' System administrators can grant or revoke specific user access instantly by adding or removing individual public keys from a server, eliminating the need to reset global account passwords.

== See Also ==
* [[Secure Shell]]
* [[Public-key cryptography]]
* [[ssh-keygen]]

[[Category:Computer access control]]
[[Category:Network security]]

Computer Notes/Security Services Platform

2026-09-10T00:02:20Z

Mflavell:

[[Computer Notes]] > Security Services Platform

[[Computer Notes/Security Services Platform/Accessing the K8 Cluster|Accessing the K8 Cluster]]

= Overview =

* Runs Vdefend security services

* This is an integrated security platform that can be deployed in the cloud.

* Services run inside kubanties on virtual machines

== Services include ==

* Security Intelligence

* Network Detection and Response

* Malware prevention

* Rule Analysis

= Install process =

* Install SSP on vSphere

:* Install NSX

::* Link SSP to NSX

::* Upload packages using package management.

::* Install platform features

vSphere > SSPI > NSX > NSX Features

== Package management notes ==

* Accessed from the vdefend SSP Installer

* The URL feature in upload enabled packages to be downloaded to the installer from an internal server on the air gapped network.
::* User downloads package > adds to internal server > downloads from internal server using SSPI

* Packages are signed, only signed packages are allowed.

= Components =

== vSphere ==

* vSphere controls the clusters.

:* By default a cluster has 3 hosts

:* This default is often expanded

* Virtual machines are started on the hosts

:* SSPI and NSX run on their own VM's

:* Other VM's include:

::* Ssp-service-controller
::* SSP-servie-md-0-worker '''two of these'''

This configuration gives a total of 5 VM's and 3 Guest OS in a basic configuration.

== NSX ==

* Management is performed in NSX.

:* After deployment of the NSX connect to the web UI using IP / FQDN

'''Features are based off the configuration you set in NSX:'''

* Security Intelligence

::This feature provides distributed visibility and policy recommendations within an NSX environment, and lets you visualize security posture, analyze traffic flows, and create micro-segmentation policies.

* Network Detection and Response (NDR)

::This feature continuously monitors your network for threats and anomalous behavior, using techniques like network traffic analysis, IDS (Intrusion Detection System), IPS (Intrusion Prevention System), and advanced threat analysis, and then responds to identified threats.

* Malware Prevention Service (MPS)

::This feature provides file-level protection against known and unknown malicious files, including zero-day threats, by analyzing traffic and extracting files for analysis.

*Network Traffic Analysis (NTA)

::This feature monitors and inspects network traffic patterns and identifies anomalies or suspicious behavior.

*Metrics

::This feature collects point-in-time, time-series, and lifetime data to let you perform analyses (such as Top N) of your environment.

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/security-services-platform-overview/key-concepts.html]

=== Private IP Ranges ===

* Defined in security intelligence

* These networks contain unsecured data

* Defining them is a ''must'' for the system to function correctly

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/overview-of-nsx-intelligence/managing-private-ip-ranges-for-nsx-intelligence.html]

=== Distributed Firewall ===

* This is a firewall that is deployed on each VM.

* Works the same way as a security group in AWS.

* Rules are loaded from NSX with NSX controlling the distributed firewall.

==== Advantages of the distributed firewall approach ====

* Enforces Zero trust

* Prevents lateral movement inside the security boundary (zero trust)

* Parameter security (ie hardware firewalls) are no longer sufficient.

:: If a node is breached no lateral movement is prevented without a ZTA.

* Firewalling each VM is also more secure than an agent based approach.

:: Again this all comes back to zero trust.

A key concept here is [[North / South & East West Network Security]]

==== How it is organized ====

* VM's are assigned to groups.

* Polices contain rules / What to do with the packet.

* Rules are assigned to source and destination groups.

Source Group + Destination group > Policy > Action

* Key point the source group and destination group much match what is defined for the policy.

:* The policy will then execute the action based on the service.

::* The action could be allow / drop / reject

* A policy can be time based.

[https://partnerportal.broadcom.com/documents/d/partner-portal/zero-trust-with-vmware-firewall-pptx?download=true more information on the distributed firewall]

= Gateway Firewall =

This is a parameter firewall with IDS/IPS configured from NSX.

This is a ''software only'' firewall designed to control north / south traffic.
[https://www.vmware.com/docs/vmware-nsx-gateway-firewall]

Manages through NSX manager alongside the distributed firewall.
[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/malware-prevention/getting-started-with-malware-prevention/overview-of-malware-prevention_service.html]

This is installed from the NXT Edge Appliance.

* This is downloaded and installed as an .ova or .iso image. [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-2/installation-guide/installing-nsx-edge/manually-deploying-nsx-edge-node-outside-of-nsx/install-nsx-edge-via-iso-file-as-a-virtual-appliance.html]

* Runs on the vSphere Client [https://www.vmware.com/products/cloud-infrastructure/vsphere]

* Can also be run on bare metal server (using ISO installer) [https://techdocs.broadcom.com/us/en/vmware-cis/nsx/nsxt-dc/3-1/installation-guide/installing-nsx-edge/install-nsx-edge-on-bare-metal.html]

== Types of Gateway ==

* Tier-0
:* Connects to external networks
:* Handles routing
:* This is a North/South gateway
:* Controlled by the NSX admin

* Tier-1
:* Handles routing between networks
:* This is a east/west gateway
:* Controlled by tenant admins

[https://vdives.com/2019/10/24/nsx-t-logical-routers-gateways/ More Details]

= SSP Data Storage =
[[SSP Data Storage]]

= External Material =

[https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-0/reference-material.html techdocs]

Computer Notes/GIT/Git Cheat Sheet

2026-08-31T17:08:52Z

Mflavell: Created page with "== Starting a Project == {| class="wikitable" |- ! Command !! Action |- | <code>git init</code> || Initialize a new local Git repository |- | <code>git clone <url></code> || Download a repository from a remote server |} == Staging & Committing == {| class="wikitable" |- ! Command !! Action |- | <code>git status</code> || Show modified, untracked, and staged files |- | <code>git add <file></code> || Stage a specific file |- | <code>git add .</code> || Stage a..."

== Starting a Project ==
{| class="wikitable"
|-
! Command !! Action
|-
| <code>git init</code> || Initialize a new local Git repository
|-
| <code>git clone <url></code> || Download a repository from a remote server
|}

== Staging & Committing ==
{| class="wikitable"
|-
! Command !! Action
|-
| <code>git status</code> || Show modified, untracked, and staged files
|-
| <code>git add <file></code> || Stage a specific file
|-
| <code>git add .</code> || Stage all modified and new files
|-
| <code>git add -f <file></code> || Force-stage a file ignored by .gitignore
|-
| <code>git commit -m "message"</code> || Save staged snapshot with a description
|-
| <code>git commit -am "message"</code> || Stage tracked changes and commit in one step
|}

== Branching & Merging ==
{| class="wikitable"
|-
! Command !! Action
|-
| <code>git branch</code> || List all local branches
|-
| <code>git branch <name></code> || Create a new branch
|-
| <code>git switch <name></code> || Switch to an existing branch
|-
| <code>git switch -c <name></code> || Create and switch to a new branch
|-
| <code>git merge <branch></code> || Merge target branch into active branch
|-
| <code>git branch -d <name></code> || Delete a merged branch
|}

== Syncing & Remotes ==
{| class="wikitable"
|-
! Command !! Action
|-
| <code>git remote add origin <url></code> || Link local repository to a remote URL
|-
| <code>git fetch</code> || Download remote changes without merging
|-
| <code>git pull</code> || Fetch and merge changes from remote repository
|-
| <code>git push -u origin <branch></code> || Upload commits and set default remote branch
|-
| <code>git push</code> || Upload commits to linked remote branch
|}

== Viewing History & Files ==
{| class="wikitable"
|-
! Command !! Action
|-
| <code>git log --oneline</code> || View condensed commit history
|-
| <code>git diff</code> || Show changes made to unstaged files
|-
| <code>git diff --staged</code> || Show changes staged for the next commit
|-
| <code>git ls-files</code> || List all files currently tracked by Git
|}

== Undoing Changes ==
{| class="wikitable"
|-
! Command !! Action
|-
| <code>git restore <file></code> || Discard uncommitted changes in a file
|-
| <code>git restore --staged <file></code> || Unstage a file without losing changes
|-
| <code>git reset HEAD~1</code> || Undo last commit, keeping changes locally
|-
| <code>git reset --hard HEAD~1</code> || Permanently discard last commit and all work
|-
| <code>git commit --amend</code> || Add staged changes to or edit the last commit
|}

Computer Notes/GIT

2026-08-31T17:08:33Z

Mflavell:

= Setting up a private GIT repo in linux =

Generate an SSH key:

ssh-keygen -t ed25519 -C "your_email@example.com"

'''The email must match your github email!!!'''

Start the SSH agent & Add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Copy the public key:

cat ~/.ssh/id_ed25519.pub

Add the key to github:

::* Go to Settings -> SSH and GPG keys -> New SSH Key.

::* Give it a title (like "Linux Desktop"), paste the key into the field, and save.

Clone what you need:

git clone git@github.com:username/private-repo.git

= The git process =

** Clone the repo

** Add / Modify files > git add (add the files you want to submit)

** git status (Double check list)

** git commit (saves locally)

** git push (upload changes)

= Useful commands =

====Add the a folder to git====

git add '''path'''

====Remove something that is staged====

git restore --staged '''path'''

====Check what is staged====

git status

====Commit the changes====

git commit -m “Message for commit”

or to amend a commit

git commit –amend -m “Message for commit”

====Uploading changes====

git push

[[Computer Notes/GIT/Git Cheat Sheet|Git Cheat Sheet]]