Manage Serverless network security (traffic filters): create, update, and delete IP filters and AWS PrivateLink VPC filters. Use when restricting network access or configuring private connectivity.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Manage Serverless network security (traffic filters): create, update, and delete IP filters and AWS PrivateLink VPC filters. Use when restricting network access or configuring private connectivity.
compatibility
Requires Python 3.8+, network access to the Elastic Cloud API (api.elastic-cloud.com). Environment variables: EC_API_KEY (required, set by cloud-setup), EC_BASE_URL (optional, defaults to https://api.elastic-cloud.com).
metadata
{"author":"elastic","version":"0.1.0"}
Cloud Network Security
Manage network security policies for Elastic Cloud Serverless projects: IP filters to allowlist specific IPs or CIDRs,
and VPC filters (AWS PrivateLink) to restrict traffic to specific VPC endpoints.
Prerequisite: This skill assumes the cloud-setup skill has already run — EC_API_KEY is set in the
environment and the organization context is established. If EC_API_KEY is missing, instruct the agent to invoke
cloud-setup first. Do NOT prompt the user for an API key directly.
For project creation and day-2 operations (including associating filters with projects), see cloud-create-project
and cloud-manage-project. For identity and access management (users, roles, API keys), see
cloud-access-management.
This skill uses network security as the umbrella term, aligned with the Elastic Cloud UI direction. The underlying
API uses traffic filters — you will see traffic-filters in endpoint paths and traffic_filters in JSON fields.
When a user or agent says "traffic filter," they mean the same thing as "network security policy." The two filter types
are IP filters (type ip) and VPC filters (type vpce).
Jobs to Be Done
Create an IP filter to restrict ingress to specific IPs or CIDR blocks
Create a VPC filter (AWS PrivateLink) to restrict traffic to specific VPC endpoint IDs
List, inspect, update, and delete network security policies
Look up PrivateLink region metadata (service names, domain names, availability zones)
Associate or disassociate filters with Serverless projects (delegates to cloud-manage-project)
Audit the current network security posture for an organization
Prerequisites and permissions
Item
Description
EC_API_KEY
Cloud API key (set by cloud-setup). Required for all operations.
Region
Filters are region-scoped. The user must specify the target region when creating filters.
Project IDs
Required only when associating filters with projects (handled by cloud-manage-project).
Run python3 skills/cloud/network-security/scripts/cloud_network_security.py list-filters to verify that EC_API_KEY
is valid before proceeding with any operation.
Operation-level permissions
The following permissions are required for common network security operations in Elastic Cloud Serverless.
Operation
Required permission
List filters / get metadata
Any organization member
Create / update / delete filters
Organization owner (organization-admin)
Associate filters with projects
Organization owner or project Admin
This skill does not perform a separate role pre-check. Attempt the requested operation and let the API enforce
authorization. If the API returns an authorization error (for example, 403 Forbidden), stop and ask the user to verify
the provided API key permissions.
Manual setup fallback (when cloud-setup is unavailable)
If this skill is installed standalone and cloud-setup is not available, instruct the user to configure Cloud
environment variables manually before running commands. Never ask the user to paste API keys in chat.
Variable
Required
Description
EC_API_KEY
Yes
Elastic Cloud API key (see permissions table above for required roles by operation).
EC_BASE_URL
No
Cloud API base URL (default: https://api.elastic-cloud.com).
Note: If EC_API_KEY is missing, or the user does not have a Cloud API key yet, direct the user to generate one
at Elastic Cloud API keys, then configure it locally using the steps below.
Preferred method (agent-friendly): create a .env file in the project root:
Terminal exports may not be visible to sandboxed agents running in separate shell sessions, so prefer .env when using
an agent.
Decomposing Network Security Requests
When the user describes a network security need in natural language (for example, "restrict my search project to our
office IP"), break the request into discrete tasks before executing.
Step 1 — Identify the components
Component
Question to answer
Filter type
IP filter (public IPs/CIDRs) or VPC filter (AWS PrivateLink endpoint)?
Region
Which AWS region are the target projects in?
Rules
What source IPs, CIDRs, or VPC endpoint IDs should be allowed?
Scope
Apply to all new projects by default, or specific projects only?
Projects
Which existing projects should this filter be associated with?
Step 2 — Check existing state
Before creating a new filter, check what already exists:
Filter hygiene: If an existing filter already covers the same source rules for the same purpose, reuse it
instead of creating a duplicate. Filters are region-scoped and can be associated with multiple projects, so a single
filter with the right rules serves many projects. Two filters with identical source rules are fine when they serve
different purposes (for example, different teams managing their own policies), but creating a second filter for the same
purpose is unnecessary.
Step 3 — Create the filter
Run the appropriate command from skills/cloud/network-security/scripts/cloud_network_security.py.
Step 4 — Associate with projects
Filter association is managed using the project PATCH endpoint. Use cloud-manage-project to associate or
disassociate filters:
When updating associations, provide the complete list of filter IDs. Any filter not included in the list is
disassociated from the project.
Step 5 — Verify
After execution, list filters again or GET the project to confirm the change took effect.
IP Filters versus VPC Filters
Aspect
IP Filter (ip)
VPC Filter (vpce)
Purpose
Allowlist public IP addresses or CIDR blocks
Restrict traffic to specific AWS VPC endpoint IDs
Use case
Office IPs, CI/CD runners, partner access
Private connectivity without public internet exposure
Source format
IP address or CIDR (for example, 203.0.113.0/24)
AWS VPC endpoint ID (for example, vpce-0abc123def456)
Network path
Public internet
AWS PrivateLink (private, never leaves AWS network)
Prerequisite
None
VPC endpoint and DNS record created in AWS console first
Key concept: Private connectivity in AWS is accepted by default in Elastic Cloud. Creating a VPC filter is only
needed to restrict traffic to specific VPC endpoint IDs. If you only need private connectivity (without
filtering), create the VPC endpoint and DNS record in AWS — no filter is needed on the Elastic Cloud side.
Examples
Allowlist an office IP range
Prompt: "Only allow traffic from our office network 203.0.113.0/24 to projects in us-east-1."
python3 skills/cloud/network-security/scripts/cloud_network_security.py delete-filter --filter-id tf-67890 --dry-run
# Review what would be deleted, then confirm:
python3 skills/cloud/network-security/scripts/cloud_network_security.py delete-filter --filter-id tf-67890
Guidelines
If EC_API_KEY is not set, do not prompt the user — instruct the agent to invoke cloud-setup first.
Always confirm destructive actions (delete filter) with the user before executing.
Filters are region-scoped: a filter created in us-east-1 can only be associated with projects in that region.
Filter hygiene — reuse, scope, and clean up:
Before creating a filter, always run list-filters and check whether an existing filter for the same purpose
already has the required source rules. Filters can be associated with multiple projects, so one filter with the
right rules is better than duplicates.
Duplicate filters means filters for the same purpose with identical source rules — not merely overlapping IPs. Two
filters covering different project groups with the same CIDR are legitimate.
Review unused filters periodically. If a filter is no longer associated with any project, prompt the user to delete
it to reduce clutter.
Updating rules replaces the entire rule set. When adding a rule using PATCH, include all existing rules plus the
new one. Omitting an existing rule removes it.
Deleting a filter fails if it is still associated with a project. Disassociate first using
cloud-manage-project (PATCH the project with the filter removed from the traffic_filters list), then delete.
include_by_default automatically associates the filter with all new projects in the region. Use with caution — it
affects every future project.
For project association and disassociation, delegate to the cloud-manage-project skill. This skill manages filter
definitions only.
For identity and access management (users, roles, API keys), see cloud-access-management.
For Elasticsearch-level security (native users, role mappings, DLS/FLS), see elasticsearch-authz.
