CVE-2026-119115: AWS Private CA Kubernetes Issuer Authorization

CVE-2026-119115 affects AWS Private CA Connector for Kubernetes, also known as aws-privateca-issuer. AWS describes an issuer-resolution authorization issue: under certain conditions, an authenticated user whose approval policy authorizes only a namespace-scoped issuer could obtain certificates signed by a cluster-scoped issuer they were not authorized to use. The advisory says the resulting certificates can include subordinate CA certificates. Official advisory.

This is a vulnerability in the AWS connector and EKS add-on, not in Kubernetes core. AWS says the fix is available in aws-privateca-issuer v1.10.1 and EKS add-on v1.10.1-eksbuild.1. The upgrade has an operational prerequisite: audit issuerRef.kind in CertificateRequest, Certificate, and Ingress resources. The fixed behavior enforces an exact kind-to-scope match, so requests that previously relied on lenient resolution can fail or remain pending after upgrade.

For platform teams, the key decision is not simply “patch now or later.” It is “patch with a validated issuer inventory and renewal plan.” A rushed upgrade without that inventory can surface latent misconfiguration and interrupt certificate issuance or renewal. Delaying indefinitely leaves an authorization weakness in place. A staged rollout with explicit issuer references addresses both risks.

The scope of the flaw

The AWS Security Bulletin 2026-156 identifies the affected product as AWS Private CA Connector for Kubernetes, an external issuer for cert-manager that requests signing from AWS Private Certificate Authority. The vulnerable condition concerns authorization during issuer resolution. It does not mean any authenticated cluster user automatically has unrestricted certificate authority access; the notice describes a specific combination of authenticated access, an approval policy scoped to a namespaced issuer, and an issuer-resolution path that could reach a cluster-scoped issuer.

The affected releases are:

अवयव	प्रभावित संस्करण	Fixed version
aws-privateca-issuer	Earlier than v1.10.1	v1.10.1 or later
AWS Private CA Connector for Kubernetes EKS add-on	Earlier than v1.10.1-eksbuild.1	v1.10.1-eksbuild.1 or later

Use the CVE record और GitHub security advisory GHSA-hjrh-q6pg-mh82 for identifier matching, but use AWS’s bulletin for the product-specific fix and migration behavior. The AWS Private CA Connector project documents the integration; the AWS EKS add-on documentation explains the managed add-on lifecycle. Neither generic add-on management nor an upstream source checkout proves the version currently running in a cluster.

Namespaced and cluster-scoped issuers

cert-manager supports both an Issuer, scoped to a namespace, and a ClusterIssuer, which is cluster-scoped. AWS’s connector uses corresponding issuer kinds: AWSPCAIssuer और AWSPCAClusterIssuer. The namespace boundary is meaningful: a namespace-scoped workload should not gain the ability to request certificates through an issuer intended for cluster-wide use unless an explicit policy grants that authority.

The cert-manager issuer concept documentation describes the difference between namespaced and cluster-scoped issuers. Its Certificate resource documentation explains how certificate requests refer to issuer objects. Those pages establish general object semantics, while the AWS advisory describes the vulnerable issuer resolution and corrected validation.

The certificate’s risk depends on what the selected AWS Private CA is allowed to sign and how the resulting certificate is trusted by workloads, clients, and other services. A subordinate CA certificate can have greater downstream signing significance than a leaf certificate, but do not assume it is automatically accepted everywhere. Review CA constraints, template permissions, certificate profiles, trust stores, issuance policies, and actual distribution paths.

Audit issuer references before upgrading

AWS states that v1.10.1 requires issuerRef.kind to be exactly AWSPCAIssuer या AWSPCAClusterIssuer and to match the scope of the referenced issuer. The bulletin calls out several upgrade consequences:

• A missing or incorrect issuerRef.kind, including kind: Issuer in an Ingress flow that did not specify the AWS issuer kind, is marked Failed.
• एक AWSPCAIssuer reference to a cluster-scoped issuer remains Pending indefinitely.
• Certificate requests that relied on the prior lenient resolution stop renewing after upgrade; services may be affected when those certificates expire.

Before the change, enumerate CertificateRequest, Certificate, and Ingress resources across all namespaces and clusters. Include generated resources and GitOps templates, not only currently healthy Certificate objects. For every issuer reference, record the namespace, kind, name, intended issuer scope, approval policy, and renewal deadline. Search controller logs for existing Failed or Pending requests as a baseline.

Correct references at the source of truth. If manifests are managed by Helm, Kustomize, Terraform, or another GitOps system, update those definitions and reconcile them before the upgrade. A one-off kubectl edit may temporarily repair a live resource only for the controller to revert it. Validate that the requested kind matches the actual AWS issuer object and the policy expected for that workload.

The Kubernetes RBAC documentation is useful when reviewing who can create or approve certificate requests. RBAC is not a complete replacement for issuer-level authorization: the connector’s approval and resolution behavior also matters. Map Kubernetes identities and service accounts to the policies that govern certificate issuance rather than relying on namespace names alone.

Upgrade with a renewal safety plan

1. Inventory the connector or EKS add-on version in every cluster and region.
2. Export and classify issuer references, approval policies, and certificate renewal dates.
3. Fix missing or mismatched issuerRef.kind values in the declarative source of truth.
4. Test the fixed release in a representative non-production cluster, including both namespaced and cluster-scoped issuance paths that are authorized by policy.
5. Upgrade to v1.10.1 or EKS add-on v1.10.1-eksbuild.1, as applicable.
6. Verify the running controller/add-on version, successful certificate requests, renewals, and controller health.
7. Review certificates issued during the affected period, especially unexpected issuer chains or subordinate CA certificates.

Do not create a test certificate through a production CA merely to prove the upgrade. Use a non-production CA or pre-approved test template. Do not weaken approval policies or grant cluster-scoped issuer access temporarily to make a failing request succeed; that masks the boundary the upgrade is intended to enforce.

For an EKS managed add-on, check the cluster’s add-on version and update procedure against AWS’s current documentation. For a self-managed installation, verify the deployment image digest and controller arguments. A repository’s latest release page is not evidence that a cluster has already been upgraded.

Certificate review if the cluster was affected

If the vulnerable version was in use, assess whether the preconditions existed: a user had authenticated access, the approval policy was intended to constrain that user to a namespace-scoped issuer, and the affected connector could resolve an unauthorized cluster-scoped issuer. Review certificate requests and their approval actors for unexpected issuer kinds, namespaces, subjects, SANs, validity periods, and CA status. Compare certificate serial numbers and issuance times against the CA audit trail.

For a potentially unauthorized certificate, trace where it was stored, mounted, distributed, and trusted. A leaf certificate used only by one service has a different response scope from a subordinate CA certificate trusted by many clients. Consult the CA owner and application owners before revoking certificates or rotating trust anchors. Revocation can break production dependencies; failing to revoke an abused certificate can leave an attacker with continuing access. Make the decision based on evidence and the certificate’s actual trust path.

Preserve Kubernetes audit logs, controller logs, CertificateRequest objects, CA issuance records, and GitOps history. Correlate identity, namespace, approval decision, issuer reference, certificate metadata, and downstream use. An unexpected resource by itself is not proof of malicious issuance; it may be a failed deployment or a stale manifest. Record confirmed unauthorized events separately from unresolved anomalies.

Safe configuration validation

The following pseudocode expresses a static policy check for a test fixture. It does not talk to a cluster, issue a certificate, or exploit the CVE:

def issuer_kind_matches_scope(kind: str, scope: str) -> bool:
    expected = {
        "namespace": "AWSPCAIssuer",
        "cluster": "AWSPCAClusterIssuer",
    }
    return expected.get(scope) == kind

assert issuer_kind_matches_scope("AWSPCAIssuer", "namespace")
assert issuer_kind_matches_scope("AWSPCAClusterIssuer", "cluster")
assert not issuer_kind_matches_scope("AWSPCAIssuer", "cluster")
assert not issuer_kind_matches_scope("Issuer", "namespace")

Use an organization-approved parser for YAML and validate the actual resource’s issuerRef.kind and issuer scope. Do not write a string-matching check that assumes every file uses identical formatting. A test suite should fail closed when the reference is absent, malformed, or points to a resource with a different scope. Run the check in CI against the configuration that will be deployed.

Build an issuer ownership map

Certificate issuance often spans several independent control planes. Kubernetes RBAC decides who may create or modify resources. cert-manager watches Certificate and CertificateRequest objects. The AWS connector translates eligible requests into AWS Private CA operations. Approval policies may constrain which requests are authorized. The CA itself has permissions, templates, and trust relationships. A workload eventually consumes the certificate. A useful review maps all of these steps instead of treating issuerRef as the only control.

For every namespace-scoped issuer, record the namespace owner, intended workloads, allowed certificate profiles, approval path, and CA identifier. For every cluster-scoped issuer, record which platform team owns it, which namespaces may use it, what policy enforces that boundary, and what kinds of certificates it can issue. Map service accounts and human identities to the roles that can create, approve, or alter each relevant resource. This inventory helps answer whether the vulnerability’s described preconditions were present and prevents a simple naming convention from being mistaken for authorization.

Check whether an issuer can issue only leaf certificates or can also request subordinate CA material. Inspect the actual CA configuration, template permissions, path-length constraints, key usage, and policy controls. Then inspect how trust is distributed: a certificate may be mounted into one pod, placed in a shared secret, published in a service mesh, or installed in a broader trust store. The same issued certificate can have very different reach depending on those downstream choices.

Treat the inventory as sensitive infrastructure documentation. Avoid including private keys or certificate contents when they are not needed. A public certificate’s metadata may still reveal internal names or topology, so limit distribution to platform owners and authorized responders.

Upgrade compatibility and certificate continuity

The stricter issuer-kind check is a security improvement, but it can expose manifests that were accepted under lenient resolution. Before upgrading, query the Kubernetes API for all relevant resource types across all namespaces and clusters. Include generated CertificateRequests, Ingress annotations, chart templates, and custom operators. Some objects may be created only during renewal, so inspect their source templates even if no current request is failing.

Build a table containing the resource name, namespace, issuerRef.name, issuerRef.kind, expected scope, current controller result, certificate expiration, and owner. Flag references where kind is missing, generic, or inconsistent with the target. The AWS bulletin explicitly notes that kind: Issuer may be set by cert-manager for Ingress annotations that do not specify an issuer kind; this is a compatibility issue to validate in the deployed configuration, not a reason to weaken the updated check.

Prioritize near-expiry certificates and critical endpoints when scheduling the rollout. A request that remains Pending may not affect service immediately if the current certificate is still valid, but it can cause an outage when that certificate expires. Define renewal windows and alert thresholds, and confirm the monitoring can distinguish a current valid certificate from a new request that failed. Test renewal in a pre-production cluster using the same chart and admission policies as production.

If a request fails after upgrade, correct the manifest at its source of truth and reconcile it. Do not respond by downgrading the controller or broadening issuer permissions without review. A temporary exception could restore issuance while reintroducing an unsafe boundary. If the service needs urgent continuity, use a documented emergency issuance process with explicit approval, restricted identity, and a post-event review.

Assess certificates issued during the vulnerable window

For each cluster that ran an affected version, identify the window between the introduction of the vulnerable connector and the fixed rollout. Pull CertificateRequest and Certificate objects, issuer references, approval decisions, and connector logs. Where available, compare with AWS Private CA audit records and certificate serial numbers. Correlate the requesting identity, namespace, workload, certificate subject and SANs, duration, issuer, CA chain, and whether the certificate included CA-signing capability.

Prioritize certificates with unexpected issuer references, unusual identities, unknown workloads, broad SANs, or signing capability. These are investigation leads, not proof that CVE-2026-119115 was exploited. A legitimate automation rollout can create an unusual object; an exploit may leave incomplete logs. Label findings as confirmed, likely, or unresolved and retain the source evidence behind each assessment.

Trace each suspicious certificate through its consumers. Determine whether it was mounted or copied, whether a private key was generated in the cluster, whether the certificate was presented to another service, and which trust stores would accept it. Do not assume that revoking the certificate is sufficient if a private key or subordinate certificate has been copied. Conversely, do not revoke an entire CA or trust bundle when a narrower leaf certificate replacement is enough; broad trust changes can disrupt many services.

Coordinate revocation and replacement with CA administrators and workload owners. A certificate rotation may require a staged deployment, overlapping trust, service restart, or client cache refresh. Preserve enough information to establish which certificates were revoked and which workloads received replacements. If the investigation identifies actual unauthorized issuance, follow the organization’s incident process and assess notification obligations with the relevant stakeholders.

Least privilege across Kubernetes and AWS

Review Kubernetes permissions for creating Certificate, CertificateRequest, Ingress, and issuer objects. Review approval rights separately from object creation. A developer who can create a request but cannot approve it has a different authority from a controller or administrator that can approve and bind it to a CA. Check whether any role grants broad access to cluster-scoped issuer resources and whether service accounts are shared across namespaces.

Review the AWS identity used by the connector. It should have only the CA actions and resources required by the issuer configuration. Confirm trust relationships, service-account binding, and any role assumption mechanism. Avoid static AWS keys in Kubernetes secrets if a supported short-lived identity mechanism is available. Separate test and production CAs and identities so a development workload cannot request certificates from a production authority.

The Kubernetes RBAC model is an important part of that review, but RBAC does not fully express certificate policy. Admission control, cert-manager approval, connector configuration, AWS IAM, and CA templates can all affect the outcome. Document which layer enforces each decision and test the combined behavior. A control that is duplicated should fail consistently rather than creating contradictory outcomes that operators work around.

Safe pre-upgrade validation

Use a YAML parser or Kubernetes-aware policy engine to inspect manifests. The test should compare the reference kind with the intended scope and flag missing values. It should also detect generic or unsupported issuer kinds for AWS-backed resources. Run this check in CI on both application repositories and platform repositories; an issuer reference may be defined in a Helm chart rather than a standalone YAML file.

In a test cluster, create one namespace-scoped issuer and one cluster-scoped issuer connected to a non-production CA. Confirm that authorized test requests succeed and unauthorized combinations are rejected after the fix. Use synthetic identities and certificates, and avoid including customer names or production SANs in test data. Do not attempt the unauthorized cross-scope request against a production CA as a validation shortcut.

Record the controller image or add-on version before and after the test, along with request status, controller events, and the certificate chain. A successful test means the test policy behaved as expected; it does not prove that no historical certificate was improperly issued. Keep prospective configuration validation and retrospective incident review as separate work items.

Understand the certificate issuance chain

Certificate issuance in Kubernetes crosses several trust boundaries. A user or workload creates a Certificate or CertificateRequest. Kubernetes authentication identifies the caller, and RBAC determines whether that identity can create or modify the object. cert-manager observes eligible resources and resolves the issuer reference. The AWS connector submits a request to AWS Private CA using its AWS identity and any configured approval controls. The CA applies its templates and policy, returns a certificate, and the controller stores the result for the workload. A weakness in issuer resolution can therefore connect a namespace-level Kubernetes identity to a cluster-level signing authority even when each component appears to have a policy.

The vulnerability is specifically about the connector’s authorization while resolving an issuer. Do not infer that a cluster role, CA policy, or certificate template was bypassed in every installation. Instead, establish which checks were configured and which identity enforced them. Review whether the connector accepted a namespace-scoped approval decision while resolving a cluster-scoped issuer, whether the CA role could request subordinate CA certificates, and whether the resulting certificate would be trusted by any workload.

A certificate is a signed assertion, not merely a file. Its practical effect depends on subject, SANs, key usage, extended key usage, validity period, issuer chain, private-key control, and the trust stores that accept it. A leaf certificate for one service can be serious if it impersonates a production endpoint, but it usually has a different scope from a subordinate CA certificate that can sign additional certificates. The AWS advisory explicitly mentions subordinate CA certificates as a possible issuance outcome under the described conditions; evaluate the actual CA templates and trust paths before estimating scope.

Map authorization owners and policy layers

Create a responsibility map for each CA integration:

परत	Questions to answer	Evidence to retain
Kubernetes identity	Which human, service account, or controller creates the request?	Role bindings, service-account mapping, audit events
Resource permissions	Who can create, edit, approve, or delete request and issuer objects?	RBAC policy and approval configuration
Issuer resolution	Which kind and namespace are accepted for each issuer reference?	Connector version and manifest inventory
AWS identity	Which role does the connector assume, and what CA actions can it perform?	Trust policy and scoped permission policy
CA policy	Which templates, names, usages, and validity periods are permitted?	CA configuration and issuance policy
Certificate distribution	Where is the certificate and private key stored or trusted?	Secret references, mounts, trust bundle inventory

For each policy decision, record the owner and the intended source of truth. A Kubernetes namespace label is not a policy unless a controller enforces it. A chart template is not the running resource unless the deployment reconciled it. An AWS role is not scoped merely because its name includes a namespace. Map the identity that creates the request through the connector and to the AWS role that signs it.

Review whether multiple namespaces share one issuer, AWS role, or CA. Shared infrastructure can be appropriate, but the authorization boundaries must be explicit. If one workload needs a cluster-scoped issuer, document why and limit its Kubernetes permissions and certificate profile. If a namespace requires only a leaf certificate, it should not inherit the ability to obtain a subordinate CA certificate through a broad template.

Plan a low-risk upgrade window

Upgrading the connector while applications are close to certificate expiry can create a service incident if references fail validation. Begin by grouping resources by expiration time and criticality. Identify certificates that expire soon, externally exposed endpoints, internal service-mesh identities, admission webhooks, and any control-plane integration that depends on the connector. Confirm alerting on renewal failures and controller health before the change.

Use a non-production cluster with the same chart versions, admission controls, issuer kinds, approval policies, and EKS add-on mechanism as production. Test one namespaced issuer and one cluster-scoped issuer through an authorized flow. Also test missing or mismatched kinds and verify that the fixed controller rejects them without signing. These negative tests should run against a non-production CA with synthetic identities, not a production CA. Record controller events and resulting certificate metadata without including private-key material.

For production, fix manifests and reconcile them before changing the controller. Upgrade one cluster or a controlled subset, verify the add-on or deployment version, and observe request status and renewal behavior. Keep a list of resources that fail after the stricter check; route each to its owner rather than weakening the policy. Once the references are corrected and the canary remains healthy, proceed with the remaining clusters.

Rollback planning deserves care. A downgrade might restore lenient resolution and reintroduce the vulnerable behavior. Prefer rolling back an unrelated application change while keeping the fixed connector. If rollback of the connector becomes unavoidable for availability, require an explicit risk owner, a short duration, narrow issuer access, enhanced monitoring, and a scheduled return to the fixed version. Do not normalize a downgrade as a routine remedy for manifest errors.

Certificate lifecycle and renewal assurance

Renewal is a long-running property, not a one-time deployment check. A certificate can remain valid for days or months after the connector is upgraded, while its next renewal is already configured to fail. Track current expiry, renewal window, issuer reference, and application owner for each critical certificate. Verify the new resource kind and issuer scope before the renewal window opens.

Confirm that a successful new request results in the expected certificate chain and that the workload consumes it. Some workloads read a Kubernetes Secret only at startup; others reload files automatically. A certificate can be issued correctly but remain unused until a restart. Conversely, a workload may continue using a valid prior certificate while the renewal request is Pending. Health checks should report both certificate validity and renewal state.

Use alerting that distinguishes an invalid configuration from a transient CA error. Missing issuerRef.kind, a generic Issuer kind, and a mismatch between AWSPCAIssuer और AWSPCAClusterIssuer are configuration concerns highlighted by AWS. Throttling, network interruption, or CA unavailability are different conditions. Operators should not respond to every failure by changing the issuer scope; investigate the event and preserve the intended boundary.

After a successful renewal, verify serial number, issuer, SANs, validity period, and key ownership. Do not compare private keys in logs. If the process generates a new key, ensure the workload and trust consumers have converged before discarding the prior certificate. Document when old credentials and certificates are retired so that incident response can distinguish expected overlap from unauthorized issuance.

Historical review and evidence handling

The retrospective review should begin with a complete version timeline for each cluster. Record when an affected connector or add-on was installed, when it was upgraded, whether it was restarted, and whether a previous deployment could still run. Link that timeline to certificate issuance events and Kubernetes object history. If a cluster’s audit retention is short, preserve what remains before rotating or deleting controller pods.

Review certificate requests and issued certificates for unexpected issuer kinds, names, namespaces, subjects, SANs, validity periods, CA status, and approval identities. Compare them with approved GitOps changes, service onboarding records, and the AWS Private CA audit trail. Verify whether the certificate was actually consumed by a workload or added to a trust store. A certificate request that failed is not evidence that a certificate was signed; a certificate object that exists may have been generated by a legitimate automation. Keep those distinctions explicit.

If an unexpected certificate is discovered, determine whether the private key was created in the cluster, stored in a Secret, or delivered elsewhere. Identify the certificate chain and all clients that trust it. For leaf certificates, assess whether the subject or SANs allow impersonation of a service. For subordinate CA certificates, establish the permitted path length, key usage, and whether the certificate can sign a chain accepted by production clients. These details determine whether the response should replace one workload certificate, revoke a branch of a chain, or update broader trust stores.

Do not revoke certificates in bulk before coordinating with CA and application owners. Revocation can have propagation delays and may not be checked by every client. A trust bundle update can affect many services. Preserve serial numbers, issuer details, request metadata, approval history, and relevant resource definitions in a protected evidence store. Keep private keys out of the incident ticket. If a key may have been exposed, handle it as a secret and follow the organization’s key-compromise process.

Prevent unsafe issuer references in CI

Add a Kubernetes-aware policy check to the repositories that define Certificate, CertificateRequest, Ingress annotations, and issuer objects. The policy should verify that AWS-backed resources specify AWSPCAIssuer या AWSPCAClusterIssuer explicitly and that the kind matches the scope of the named object. Reject generic Issuer where the connector requires the AWS-specific kind. Check charts and templates after rendering, because a source template may omit a value that a release overlay supplies or overrides.

The test should query the complete desired-state output, not only one YAML file. For Helm, render each environment’s values. For Kustomize, build each overlay. For GitOps, compare the rendered artifact with the live cluster and alert on drift. If a live cluster contains hand-edited resources, reconcile them back to the reviewed source after confirming the intended issuer. A static policy check cannot prove runtime authorization, but it catches missing or mismatched references before a rollout.

Keep the test fail-closed for an absent kind, unknown issuer type, or unresolvable issuer scope. If the repository intentionally uses a custom controller, make the allowed behavior explicit in a reviewed policy exception with an owner and expiration. Avoid a blanket ignore for a namespace because that converts a narrow compatibility exception into a broad issuer authorization bypass.

Include renewal readiness in release gates. A deployment can pass schema validation while a certificate is about to expire and its next renewal will fail. A release check should alert on critical certificates with missing/mismatched kinds and identify affected service owners. For production changes, require a canary cluster or documented equivalent validation and a rollback plan that preserves the fixed connector when possible.

Incident decision points

The incident lead should answer these questions in order:

1. Did an affected connector or add-on version run in the cluster, and during what period?
2. Were the described conditions present: authenticated access, a policy intended to allow only a namespace-scoped issuer, and a path to a cluster-scoped issuer?
3. Did any request receive approval, and which identity or controller approved it?
4. Was a certificate actually signed by the cluster-scoped issuer, and what were its subject, SANs, usage, and chain?
5. Was the certificate or key distributed to a workload, client, or trust store?
6. What is the narrowest remediation that removes unauthorized trust without breaking unrelated services?

This sequence prevents the investigation from jumping from “vulnerable version was installed” to “all certificates are compromised.” It also prevents the opposite mistake of ignoring a suspicious signed certificate because no application outage occurred. Patch the connector regardless of whether historical exploitation is confirmed; use the evidence questions to scope certificate replacement and incident communications.

If a potentially unauthorized subordinate CA certificate is found, escalate to the CA owner immediately. Review whether it could issue certificates accepted by clients, whether it was used to sign additional material, and whether those descendants were distributed. Avoid discussing only the initial certificate if a chain could have been created. Conversely, do not assume descendants exist without evidence. Preserve public certificate artifacts and issuance records while restricting access to private keys and internal topology data.

For an unresolved issuer reference after upgrade, prioritize certificates by service criticality and expiry. Correct the declarative manifest, reconcile the resource, verify issuance with a non-production or approved production process, and confirm the workload has consumed the new certificate. Do not downgrade as the default path. If the service is at risk, use an approved emergency certificate process with explicit owner, narrow identity, and post-change review.

Evidence that separates configuration drift from abuse

The most difficult part of this incident is often not the version check but the interpretation of incomplete evidence. A cluster may contain an issuer reference that is invalid under v1.10.1 because the manifest omitted issuerRef.kind; that finding demonstrates compatibility risk, not historical unauthorized signing. Conversely, a clean current manifest does not prove that an older release never accepted a cross-scope reference. The investigation needs a timeline that joins configuration, controller behavior, identity, and CA records.

Start with the desired state that was actually rendered and applied during the affected period. Retain the Git commit, Helm values, Kustomize output, admission mutations, and deployment revision. Then compare those artifacts with the live CertificateRequest and Certificate objects. A request can be generated from an annotation, a chart default, or an operator rather than from the file an investigator first opens. Record the transformation path so that an omitted kind, a defaulted generic kind, and an explicit AWS kind are not treated as the same condition.

Next, correlate Kubernetes audit events with connector logs. The useful fields include authenticated username or service account, verb, resource, namespace, object name, request timestamp, approval actor, and resulting status. Connector logs should be retained with timestamps and deployment identity, but redact certificate contents and any sensitive authorization material before exporting them. If audit retention is incomplete, mark the gap and use surviving object metadata, GitOps history, and CA audit records as corroborating evidence rather than filling the gap with assumptions.

Finally, compare the certificate serial number and issuer with the AWS Private CA issuance record. A CertificateRequest with an unusual issuerRef is an investigation lead; a signed certificate with matching CA audit evidence is a stronger finding. A certificate that was signed but never distributed has a different response from one mounted into a shared trust bundle. This evidence ladder keeps patch validation, exposure assessment, and incident declaration as separate decisions.

Designing negative tests for issuer boundaries

Positive tests alone are insufficient for this vulnerability class. A test suite should prove that an authorized namespace-scoped request succeeds, an authorized cluster-scoped request succeeds when policy allows it, and a mismatched or absent kind is rejected without invoking the production CA. Use a disposable cluster or an isolated namespace with a non-production CA and synthetic service names. The test identity should be known and low privilege so that an unexpected success is easy to attribute and cannot create a trusted production certificate.

For each test, capture the rendered manifest, the issuer object’s scope, the approval decision, controller events, request status, and resulting certificate metadata. Do not capture private keys in test logs. The negative case should assert both the immediate status and the absence of a CA issuance event. If the controller reports Pending rather than Failed, the test should still fail because indefinite Pending can become a renewal outage. A test that merely checks that no certificate appeared may miss a request that is stuck and will fail later under load or at expiry.

Repeat the matrix after every connector upgrade, cert-manager upgrade, chart change, and admission-policy change. Keep one test for Ingress-driven issuance because annotation defaults can produce a generic Issuer kind even when a platform engineer expects the AWS-specific kind. Keep another test for directly created Certificate resources and a third for generated CertificateRequests. These paths exercise different sources of issuer references and help prevent a fix in one template from leaving another path exposed.

Capacity, failure handling, and renewal queues

A security upgrade can change the number and timing of CertificateRequests even when the intended certificate set is unchanged. Once mismatched references are corrected, a cluster may generate a burst of renewals. Check connector concurrency, AWS Private CA request quotas, controller backoff, and namespace-level rate limits before the production rollout. A queue that is safe for normal daily renewal may not be safe when hundreds of previously accepted references are corrected at once.

Define an operational response for each state: Ready with a valid certificate, Pending awaiting a corrected reference, Failed because validation rejected the request, and Failed because the CA or network returned an error. Alert on time to expiry rather than only on object status. A Pending request with 30 days of certificate validity is a planned repair; the same status with two hours remaining is an availability incident. Include the owner and issuer scope in the alert, but avoid embedding certificate contents or private key material.

If the rollout requires a temporary maintenance window, keep the old certificate serving until the replacement is issued and consumed. Verify whether the workload reloads the Secret automatically or needs a restart. For admission webhooks and service-mesh identities, test the reload behavior explicitly because a successful CA issuance does not guarantee that every consumer has adopted the new certificate. Document the overlap period and the exact condition that allows the old certificate to be retired.

Recovery when an issuer reference fails after upgrade

When a request becomes Failed or Pending after the fixed connector is installed, preserve the object and event history before editing it. Identify the source template, correct the kind and scope in the repository, and reconcile through the normal deployment path. If the object is generated by an operator, change the operator’s configuration rather than repeatedly editing its child resources. A manual edit that disappears during reconciliation can create a misleading sense of recovery.

After reconciliation, confirm that the new request has the expected issuer kind, approval actor, and CA identity. Verify the certificate’s subject, SANs, key usage, validity, and chain before declaring the service recovered. Check the consumer’s effective certificate, not just the Secret object: an application may continue presenting an expired or previous certificate until it reloads. For a high-value endpoint, perform a controlled client-side handshake from an approved monitoring location and compare the presented chain with the intended issuer.

Do not use a broad cluster-scoped issuer as a compatibility shortcut. If a workload genuinely requires a cluster-scoped issuer, document the reason, constrain the identity and certificate template, and obtain the required owner approval. If the workload does not need that authority, keep it on a namespace-scoped issuer and repair the reference instead. The fixed connector is designed to make that distinction explicit.

Ownership handoff and durable records

The platform team usually owns the connector and EKS add-on, while application teams own certificate consumers and namespace manifests. CA administrators own templates, revocation, and trust distribution. Assign a named owner to each action and retain a compact record containing the affected version, fixed version, cluster, issuer, certificate expiry, evidence status, and verification timestamp. This prevents the same request from being re-investigated during the next renewal or audit.

Close the work only when the fixed version is running on every active and failover path, declarative references are corrected, renewal monitoring is healthy, and historical review has a documented conclusion. “No evidence found” is a valid outcome when supported by retained logs and CA records, but it should not be used when the relevant period has no audit coverage. State the remaining uncertainty, the compensating controls, and the date for a follow-up review. That discipline is more useful than an absolute claim that cannot be demonstrated.

Review trust stores and certificate consumers

Issuer authorization is only one part of the eventual security boundary. After identifying certificates created during the affected period, map every consumer that could have accepted them. Kubernetes Secrets are obvious consumers, but they are not the only ones. Operators may copy certificates into config maps, external secret stores, service-mesh identities, ingress controllers, admission webhooks, load balancers, or cloud service integrations. A certificate that no longer appears in the original namespace can still be active in another system.

Build the consumer inventory from deployment manifests, Secret references, volume mounts, controller status, and approved distribution jobs. Record the certificate serial number, destination, owner, and trust decision without storing private keys in the review system. For trust bundles, identify whether the certificate was added as a leaf, an intermediate, or a root-like anchor. The same serial number can be harmless in one location and high impact in another if a broader client population trusts that location.

When replacing a certificate, decide whether the private key must also be replaced. If a key was generated in a pod and the Secret access boundary is intact, a normal renewal may be sufficient. If an unauthorized identity could read the Secret, copy the key, or use a subordinate certificate to create descendants, treat the key as potentially compromised and generate a new one. Coordinate the replacement with clients that pin certificates or public keys; an emergency rotation can otherwise produce an availability outage that obscures the security response.

For workloads that use mutual TLS, inspect both server and client trust paths. Replacing only the server certificate may leave a client certificate issued through the same unauthorized path. For webhook and control-plane integrations, verify that the new CA chain is accepted before removing the old chain, then remove the old trust material after the overlap period. Keep a dated record of which trust stores were changed and which were intentionally left unchanged with an owner-approved rationale.

Admission and policy controls around certificate requests

Admission control can reduce the chance that an unsafe issuer reference reaches the connector, but it must be aligned with the connector’s exact resource semantics. A policy should distinguish AWSPCAIssuer from AWSPCAClusterIssuer, validate the namespace of a namespaced issuer, and reject references whose target cannot be resolved in the intended scope. It should also cover generated CertificateRequests, not only the higher-level Certificate or Ingress object that caused them.

Do not rely on a single policy expression that checks only the string value of issuerRef.kind. The policy should resolve the referenced object or compare it with a reviewed inventory, because a correctly spelled kind can still point to an unexpected issuer name. Test policy behavior after cert-manager and connector upgrades, and record whether mutation or defaulting changes the kind before validation. A policy that runs before a defaulting webhook may see a different object from the one the connector later processes.

Use policy exceptions sparingly. If a legacy workload cannot be migrated immediately, give the exception an owner, expiry date, affected namespace, allowed issuer, and compensating control. Do not create a cluster-wide ignore rule for an entire issuer kind. The purpose of the exception is to manage a known migration step, not to recreate the ambiguity that the fixed connector removes.

Review policy failure modes as well. A fail-open admission outage can allow a malformed reference through, while a fail-closed outage can block legitimate certificate renewals. Define which behavior is acceptable for each resource and ensure that expiry alerts reach the service owner. Admission control should be a guardrail; it cannot replace version verification, CA audit review, or a tested renewal process.

Ongoing governance for certificate issuers

Assign an owner to every cluster-scoped issuer and every AWS Private CA identity. Keep a registry linking issuer name, Kubernetes scope, CA ARN, AWS role, approval policy, certificate profiles, allowed namespaces, and service owner. Review the registry when new namespaces, workloads, or CA templates are introduced. Remove stale issuers and permissions when a service is decommissioned.

Use distinct AWS identities and CA environments for development and production. A test cluster should not be able to issue production-trusted certificates. Where possible, separate request permissions from approval permissions and require a second review for certificates with CA-signing capability or broad SANs. The exact controls vary by deployment, but the policy should make the authority and approval path visible.

Monitor both issuance and failed renewal. Alert on unexpected issuer kinds, new cluster-scoped references, certificates with CA status, unusually broad SANs, and issuer changes outside approved deployment windows. Tune alerts with service owners so legitimate onboarding is explainable. Keep the alert payload minimal; certificate metadata can expose internal hostnames, and private keys must never be included.

Use periodic access reviews to verify that namespace owners cannot modify cluster-scoped issuer configuration and that the connector’s AWS role has only necessary CA actions. Confirm that backups and restore procedures preserve the corrected manifests and add-on version. A disaster recovery test should verify that rebuilding a cluster does not restore an old connector or a stale issuer reference.

Include this vulnerability in the next recovery exercise. Rebuild a non-production cluster from the documented source of truth, install the fixed connector, restore issuer definitions, and request a synthetic certificate using each approved scope. This catches stale backups and undocumented manual fixes before a real recovery depends on them. Retain the test result with the cluster baseline and rerun it when the CA integration changes.

Common misconceptions

• “Kubernetes itself has this CVE.” The identified component is AWS Private CA Connector for Kubernetes / aws-privateca-issuer.
• “Any unauthenticated Internet user can request certificates.” AWS’s description requires an authenticated user and specific authorization conditions.
• “Every cluster-scoped issuer can sign any certificate.” Actual permissions, CA configuration, templates, approvals, and trust distribution constrain impact.
• “Upgrade immediately without inspecting manifests.” The fixed version enforces exact kinds; known misreferences can fail or remain pending and interrupt renewal.
• “RBAC alone fixes the connector flaw.” RBAC is relevant but does not replace the connector’s issuer-resolution authorization checks.
• “A Pending certificate proves exploitation.” It may indicate an invalid issuer reference after upgrade; investigate alongside identity and CA records.

अक्सर पूछे जाने वाले प्रश्न

• What is the fixed version? aws-privateca-issuer v1.10.1 or EKS add-on v1.10.1-eksbuild.1.
• What should be audited first? issuerRef.kind in CertificateRequest, Certificate, and Ingress resources, matched to the scope of the referenced issuer.
• Why can an upgrade break renewal? Requests relying on lenient resolution may be rejected or remain pending when the kind is missing or does not match issuer scope.
• Does this affect cert-manager core? The advisory identifies the AWS connector/issuer integration, not Kubernetes core or cert-manager generally.
• Can a subordinate CA certificate be involved? AWS says certificates including subordinate CA certificates may be obtained under the described condition. Assess actual CA policy and trust distribution.
• How do I validate safely? Use static manifest checks and non-production CA resources; do not test unauthorized issuance against production.
• Should I revoke certificates? Only after identifying what may have been issued and evaluating its real trust path and application impact with the CA owner.

संदर्भ

• AWS Security Bulletin 2026-156
• GitHub Security Advisory GHSA-hjrh-q6pg-mh82
• CVE Record
• NVD record
• AWS Private CA Connector for Kubernetes repository
• aws-privateca-issuer v1.10.1 release
• AWS Private CA Connector documentation
• Amazon EKS add-ons
• cert-manager issuer concepts
• cert-manager Certificate usage
• Kubernetes RBAC
• AWS Private CA user guide
• AWS EKS add-on update guidance