Amazon EKS Hardening

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:16 AM UTC
• Version: 1.0.0

Overview

This skill is a disclosed EKS hardening API integration, but its own sample hardening output contains unsafe Kubernetes configurations that could weaken a cluster if trusted or applied.

Install only if you treat this as a draft generator and have a qualified Kubernetes operator review every manifest before use. Do not apply the sample output directly to production; validate against your EKS/Kubernetes version, avoid body-level audit logging for secrets, do not grant broad roles to default service accounts, and confirm what user/session metadata is sent to the external API.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:45

Finding

Kubernetes Secret Bodies Exposed Through RequestResponse Audit Logging

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, line 45
Vulnerability Type: Sensitive information exposure through unsafe audit configuration
Risk Level: High

Vulnerable Code Snippet:

yaml

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  omitStages:
  - RequestReceived
  resources:
  - group: ""
    resources:
    - secrets

Technical Analysis

The generated audit policy applies the RequestResponse audit level to Kubernetes Secret resources. This level records request and response bodies rather than limiting records to metadata.

Kubernetes Secret API payloads contain sensitive values in base64-encoded fields. Base64 is not encryption and can be decoded without a key. Consequently, Secret creation, modification, or retrieval operations can place credentials, tokens, certificates, and application secrets into audit records.

The exposure can extend beyond the Kubernetes control plane because audit logs are commonly forwarded to centralized logging, monitoring, archival, or security analytics systems. Every user and service with access to those systems may consequently gain indirect access to cluster secrets.

Attack Path

1. An administrator applies or adapts the generated audit policy.
2. A user, controller, or workload creates, updates, or reads a Kubernetes Secret.
3. The API server records the operation's request or response body under the RequestResponse policy level.
4. The audit record is retained locally or exported to a centralized logging service.
5. An attacker compromises a log-reading account, or an overprivileged logging user searches the audit data.
6. The attacker extracts and base64-decodes the Secret values.
7. The recovered credentials are used to access workloads, databases, cloud services, or other protected resources.

Impact Assessment

The obtainable privileges depend on the affected Secret contents. Exposure m ...[truncated 378 chars]

Remediation

View remediation

Remediation Suggestions

• Use the Metadata audit level for Secret resources so request and response bodies are not recorded.
• Add a dedicated Secret rule before broader audit rules to ensure sensitive resources receive the safer policy.
• Review audit rules for ConfigMaps, token requests, authentication objects, and custom resources that may also contain credentials.
• Restrict audit-log access through narrowly scoped IAM and Kubernetes permissions.
• Encrypt audit logs both in transit and at rest.
• Apply short, documented retention periods appropriate to operational and compliance needs.
• Prevent unrestricted export of sensitive audit events to third-party logging systems.
• Rotate any credentials that may already have been recorded under this policy.
• Add automated tests that reject generated audit policies assigning Request, RequestResponse, or equivalent body-logging levels to Secret resources.

A safer rule is:

yaml

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources:
    - secrets

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:41

Finding

Cluster-Wide View Permissions Granted to the Default Service Account

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, line 41
Vulnerability Type: Excessive Kubernetes RBAC permissions
Risk Level: High

Vulnerable Code Snippet:

yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: restrict-system-access
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: ServiceAccount
  name: default
  namespace: default

Technical Analysis

The manifest creates a ClusterRoleBinding between the built-in view ClusterRole and the default service account in the default namespace.

A ClusterRoleBinding applies the referenced permissions across the cluster rather than restricting them to one namespace. Every pod that uses this default service account can therefore inherit the cluster-wide permissions exposed by the view role. This violates least privilege and conflicts with the manifest's stated purpose of restricting system access.

Default service accounts are frequently used implicitly by workloads that do not declare a dedicated service account. As a result, unrelated applications can inherit these permissions without an explicit authorization decision. Although the standard view role generally does not permit Secret access or resource modification, it enables broad discovery and reading of many workload and configuration resources across namespaces.

Attack Path

1. An administrator applies the generated ClusterRoleBinding.
2. A pod in the default namespace runs under the default service account.
3. An attacker compromises that pod through an application vulnerability or exposed administrative interface.
4. The attacker accesses the service-account token mounted in the pod.
5. The attacker authenticates to the Kubernetes API with that token.
6. The ClusterRoleBinding authorizes cluster-wide read and enumeration operations supported by the view role.
7. The ...[truncated 817 chars]

Remediation

View remediation

Remediation Suggestions

• Remove the ClusterRoleBinding to the default service account.
• Create a dedicated service account for each workload with an explicit security boundary.
• Use namespace-scoped Role and RoleBinding resources unless cluster-wide access is demonstrably required.
• Define narrowly scoped permissions for only the required API groups, resources, resource names, and verbs.
• Set automountServiceAccountToken: false for workloads that do not need Kubernetes API access.
• Set automountServiceAccountToken: false on the default service account as an additional defense where operationally feasible.
• Inventory existing pods using the default service account before removing the binding.
• Use RBAC analysis and admission controls to reject ClusterRoleBindings targeting default service accounts.
• Add generation-time validation that prevents assigning built-in broad roles to default service accounts.

A namespace-scoped pattern should use a dedicated account:

yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: application-reader
  namespace: application
automountServiceAccountToken: true
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: application-reader
  namespace: application
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: application-reader
  namespace: application
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: application-reader
subjects:
- kind: ServiceAccount
  name: application-reader
  namespace: application

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:48

Finding

Removed PodSecurityPolicy API Presented as an Active Hardening Control

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, line 48
Vulnerability Type: Obsolete and ineffective Kubernetes security control
Risk Level: Medium

Vulnerable Code Snippet:

yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
  - ALL

Technical Analysis

The generated hardening example relies on policy/v1beta1 and the PodSecurityPolicy resource. PodSecurityPolicy has been removed from current Kubernetes releases and therefore cannot provide the represented admission control on modern EKS clusters.

Applying this manifest to an unsupported cluster is expected to fail because the API server does not recognize the resource type. If deployment automation ignores that failure or operators assume the hardening step succeeded, the cluster can remain without an effective control preventing privileged containers, privilege escalation, or retained Linux capabilities.

The manifest also does not provide a version-aware fallback to Pod Security Admission or a supported policy engine. Thus, the generated deployment guide can create a false assurance that pod restrictions are being enforced.

Attack Path

1. An administrator generates and applies the supplied hardening configuration to a modern EKS cluster.
2. The API server rejects the removed PodSecurityPolicy resource.
3. Deployment automation ignores the error, or the operator does not verify that an admission policy became active.
4. No equivalent Pod Security Admission labels or policy-engine controls are configured.
5. An attacker who already has permission to create or modify pods submits a workload with privileged settings, privilege escalation, or excessive Linux capabilities.
6. In the absence of another effective admission control, the cluster admits the workload.
7. The attacker uses the workload's e ...[truncated 686 chars]

Remediation

View remediation

Remediation Suggestions

• Replace PodSecurityPolicy generation with Kubernetes Pod Security Admission controls supported by the target EKS version.
• Apply the restricted Pod Security Standard to workload namespaces and choose an appropriate enforcement version.
• Use enforce, audit, and warn labels so violations are blocked and visible.
• Validate generated manifests against the exact Kubernetes version used by the destination EKS cluster.
• Treat unsupported API versions and failed security-policy deployments as fatal errors.
• Verify after deployment that the admission control is active and rejects a known noncompliant test workload.
• Where Pod Security Admission is insufficient, generate supported Kyverno, Gatekeeper, or another maintained policy-engine configuration.
• Add continuous tests that reject removed APIs such as policy/v1beta1 PodSecurityPolicy.

A current Pod Security Admission configuration can be applied through namespace labels:

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: application
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

This skill generates Kubernetes hardening manifests that users may apply directly to live EKS clusters, yet the description does not warn that RBAC, network policy, pod security, and encryption changes can break application connectivity, revoke access, or cause workload disruption. In this context, omission of an operational safety warning is risky because the tool is explicitly positioned for production security automation and encourages accelerated deployment workflows.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 87% confidence

Finding

The sample audit policy logs RequestResponse data for access to secrets, but the documentation does not warn that audit logs may capture sensitive material or metadata that expands exposure if logs are broadly accessible or retained insecurely. Because this is a security-focused tool, users may trust the example as safe-by-default and enable verbose logging without appropriate data minimization or log protection.

Content

No source excerpt is available for this finding.

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 50% confidence

Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 202)May include surrounding context.

md

# References

- Kong Route: https://api.mkkpro.com/hardening/amazon-eks
- API Docs: https://api.mkkpro.com:8150/docs

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 87% confidence

Finding

The OpenAPI spec defines sessionId, userId, and timestamp fields in the request body for the hardening-generation endpoint, implying transmission of user/session metadata. There is no accompanying warning in this file's natural-language descriptions about sending identifying or session-linked data, which is a missing disclosure for a manifest-style API definition.

Content

No source excerpt is available for this finding.

Vague Triggers

Low

• Category: Not specified by scanner
• Confidence: 75% confidence

Finding

This is a manifest/config file, so vague-trigger checks apply. The generate operation is described only as 'Generate Amazon EKS security hardening configuration files' without any constraints, negative examples, or narrower invocation context, which makes the activation scope underspecified for an agent integrating this OpenAPI spec.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.