{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/reject-a-tls-only-destination-for-docker-gelf-tcp-output/", "item": { "id": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/", "slug": "reject-a-tls-only-destination-for-docker-gelf-tcp-output", "url": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output.md", "json": "https://update.dsesecurity.com/api/v1/posts/reject-a-tls-only-destination-for-docker-gelf-tcp-output/" }, "title": "Reject a TLS-only destination for Docker GELF TCP output", "summary": "Docker documents that its GELF driver does not support TLS for TCP and can silently fail against TLS-protected inputs. Resolve the receiver protocol before treating logging as operational.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T17:40:48+00:00", "modified_at": "2026-10-29T17:41:39+00:00", "reviewed_on": "2026-10-29", "reading_minutes": 3, "word_count": 517, "potentially_affected": "Review scope: the Docker GELF logging driver and its documented TCP/UDP endpoint options; receiver configuration and any alternative protected transport need separate vendor review.", "dse_recommendation": "Confirm the receiver's protocol requirement before selecting a GELF endpoint, and verify actual ingestion with harmless identifiers rather than relying on container startup.", "primary_source": { "name": "Docker Docs — Graylog Extended Format logging driver", "url": "https://docs.docker.com/engine/logging/drivers/gelf/", "published_on": null, "authority": "docs.docker.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: Resolve the receiver’s transport requirement before accepting a Docker GELF logging configuration. If the intended input requires TLS, keep that requirement visible and select a separately reviewed delivery design instead of treating a TCP address as sufficient.

\n

Source fact: documented behavior

\n

The Graylog Extended Format logging driver documentation is the primary reference.

\n

Docker’s GELF documentation says the driver does not support TLS for TCP connections and that messages to TLS-protected inputs can silently fail. The gelf-address option requires a port and accepts only tcp or udp URI specifiers. The documented reconnection-count and reconnection-delay options are TCP-only; the compression-type option is UDP-only.

\n

What the source does not establish

\n

This article identifies a driver transport limit. It does not recommend unprotected transport, certify a receiver or choose a tunnel, relay or replacement driver. Have the security and logging owners review any alternative against their actual requirements; do not weaken the receiver simply to make the proposed configuration connect.

\n

Applicability questions

\n\n

DSE recommendation: agree the endpoint contract before deployment

\n

DSE recommends a short endpoint contract shared by the container and logging owners. Record the destination, scheme, port and transport-protection requirement from the receiver’s own configuration. Compare it with the driver’s documented limits before changing a workload definition.

\n

For a TLS-only input, stop the direct GELF TCP proposal and identify a separately documented alternative with the responsible owners. Keep the original protection requirement in the decision. Do not add a plausible-looking protocol option or assume a reconnect setting supplies missing transport protection.

\n

Review selected driver options against the actual protocol. Keep TCP reconnection settings distinct from UDP compression settings. Record the approved configuration in the workload’s managed definition, with secret or environment data excluded from shared examples. Make the receiver identity and expected ingestion route reviewable without exposing sensitive connection material.

\n

Define an ingestion check before calling the configuration operational. Choose a harmless marker and a destination-side observation that can identify that exact record. Pair the observation with workload and daemon diagnostics. Treat an unexplained absence as an unresolved delivery problem, even when the container itself appears healthy. Assign a recovery action without claiming that retry settings guarantee retention.

\n

Verification and evidence

\n

Proposed verification, not performed: use a dedicated test workload and approved test input. First reconcile the configured receiver protocol with the endpoint contract. Do not send important operational records through an intentionally incompatible input as an experiment.

\n

Generate a small numbered sequence of harmless messages and inspect the intended receiver for their identities and order. If a controlled connectivity interruption is approved, record reconnect observations separately from message continuity. Retain the selected transport, relevant options, daemon observations and received identifiers. Do not generalize one successful ingestion test into a guarantee of confidentiality or lossless delivery.

\n

Official references

\n\n

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.

\n", "content_text": "Bottom line: Resolve the receiver’s transport requirement before accepting a Docker GELF logging configuration. If the intended input requires TLS, keep that requirement visible and select a separately reviewed delivery design instead of treating a TCP address as sufficient.\nSource fact: documented behavior\nThe Graylog Extended Format logging driver documentation is the primary reference.\nDocker’s GELF documentation says the driver does not support TLS for TCP connections and that messages to TLS-protected inputs can silently fail. The gelf-address option requires a port and accepts only tcp or udp URI specifiers. The documented reconnection-count and reconnection-delay options are TCP-only; the compression-type option is UDP-only.\nWhat the source does not establish\nThis article identifies a driver transport limit. It does not recommend unprotected transport, certify a receiver or choose a tunnel, relay or replacement driver. Have the security and logging owners review any alternative against their actual requirements; do not weaken the receiver simply to make the proposed configuration connect.\nApplicability questions\n\nDoes the receiving input require TLS?\nWhich URI scheme and port does the proposed driver configuration select?\nDo the chosen options apply to that transport?\nWhere will the operator verify that the actual receiver retained the test message?\n\nDSE recommendation: agree the endpoint contract before deployment\nDSE recommends a short endpoint contract shared by the container and logging owners. Record the destination, scheme, port and transport-protection requirement from the receiver’s own configuration. Compare it with the driver’s documented limits before changing a workload definition.\nFor a TLS-only input, stop the direct GELF TCP proposal and identify a separately documented alternative with the responsible owners. Keep the original protection requirement in the decision. Do not add a plausible-looking protocol option or assume a reconnect setting supplies missing transport protection.\nReview selected driver options against the actual protocol. Keep TCP reconnection settings distinct from UDP compression settings. Record the approved configuration in the workload’s managed definition, with secret or environment data excluded from shared examples. Make the receiver identity and expected ingestion route reviewable without exposing sensitive connection material.\nDefine an ingestion check before calling the configuration operational. Choose a harmless marker and a destination-side observation that can identify that exact record. Pair the observation with workload and daemon diagnostics. Treat an unexplained absence as an unresolved delivery problem, even when the container itself appears healthy. Assign a recovery action without claiming that retry settings guarantee retention.\nVerification and evidence\nProposed verification, not performed: use a dedicated test workload and approved test input. First reconcile the configured receiver protocol with the endpoint contract. Do not send important operational records through an intentionally incompatible input as an experiment.\nGenerate a small numbered sequence of harmless messages and inspect the intended receiver for their identities and order. If a controlled connectivity interruption is approved, record reconnect observations separately from message continuity. Retain the selected transport, relevant options, daemon observations and received identifiers. Do not generalize one successful ingestion test into a guarantee of confidentiality or lossless delivery.\nOfficial references\n\nGraylog Extended Format logging driver — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Resolve the receiver’s transport requirement before accepting a Docker GELF logging configuration. If the intended input requires TLS, keep that requirement visible and select a separately reviewed delivery design instead of treating a TCP address as sufficient.\n\n## Source fact: documented behavior\n\nThe [Graylog Extended Format logging driver](https://docs.docker.com/engine/logging/drivers/gelf/) documentation is the primary reference.\n\nDocker’s GELF documentation says the driver does not support TLS for TCP connections and that messages to TLS-protected inputs can silently fail. The gelf-address option requires a port and accepts only tcp or udp URI specifiers. The documented reconnection-count and reconnection-delay options are TCP-only; the compression-type option is UDP-only.\n\n## What the source does not establish\n\nThis article identifies a driver transport limit. It does not recommend unprotected transport, certify a receiver or choose a tunnel, relay or replacement driver. Have the security and logging owners review any alternative against their actual requirements; do not weaken the receiver simply to make the proposed configuration connect.\n\n## Applicability questions\n\n- Does the receiving input require TLS?\n\n- Which URI scheme and port does the proposed driver configuration select?\n\n- Do the chosen options apply to that transport?\n\n- Where will the operator verify that the actual receiver retained the test message?\n\n## DSE recommendation: agree the endpoint contract before deployment\n\nDSE recommends a short endpoint contract shared by the container and logging owners. Record the destination, scheme, port and transport-protection requirement from the receiver’s own configuration. Compare it with the driver’s documented limits before changing a workload definition.\n\nFor a TLS-only input, stop the direct GELF TCP proposal and identify a separately documented alternative with the responsible owners. Keep the original protection requirement in the decision. Do not add a plausible-looking protocol option or assume a reconnect setting supplies missing transport protection.\n\nReview selected driver options against the actual protocol. Keep TCP reconnection settings distinct from UDP compression settings. Record the approved configuration in the workload’s managed definition, with secret or environment data excluded from shared examples. Make the receiver identity and expected ingestion route reviewable without exposing sensitive connection material.\n\nDefine an ingestion check before calling the configuration operational. Choose a harmless marker and a destination-side observation that can identify that exact record. Pair the observation with workload and daemon diagnostics. Treat an unexplained absence as an unresolved delivery problem, even when the container itself appears healthy. Assign a recovery action without claiming that retry settings guarantee retention.\n\n## Verification and evidence\n\nProposed verification, not performed: use a dedicated test workload and approved test input. First reconcile the configured receiver protocol with the endpoint contract. Do not send important operational records through an intentionally incompatible input as an experiment.\n\nGenerate a small numbered sequence of harmless messages and inspect the intended receiver for their identities and order. If a controlled connectivity interruption is approved, record reconnect observations separately from message continuity. Retain the selected transport, relevant options, daemon observations and received identifiers. Do not generalize one successful ingestion test into a guarantee of confidentiality or lossless delivery.\n\n## Official references\n\n- [Graylog Extended Format logging driver](https://docs.docker.com/engine/logging/drivers/gelf/) — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/", "url": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Reject a TLS-only destination for Docker GELF TCP output", "item": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/#article", "identifier": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/", "url": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/", "headline": "Reject a TLS-only destination for Docker GELF TCP output", "description": "Docker documents that its GELF driver does not support TLS for TCP and can silently fail against TLS-protected inputs.", "abstract": "Docker documents that its GELF driver does not support TLS for TCP and can silently fail against TLS-protected inputs. Resolve the receiver protocol before treating logging as operational.", "articleBody": "Bottom line: Resolve the receiver’s transport requirement before accepting a Docker GELF logging configuration. If the intended input requires TLS, keep that requirement visible and select a separately reviewed delivery design instead of treating a TCP address as sufficient.\nSource fact: documented behavior\nThe Graylog Extended Format logging driver documentation is the primary reference.\nDocker’s GELF documentation says the driver does not support TLS for TCP connections and that messages to TLS-protected inputs can silently fail. The gelf-address option requires a port and accepts only tcp or udp URI specifiers. The documented reconnection-count and reconnection-delay options are TCP-only; the compression-type option is UDP-only.\nWhat the source does not establish\nThis article identifies a driver transport limit. It does not recommend unprotected transport, certify a receiver or choose a tunnel, relay or replacement driver. Have the security and logging owners review any alternative against their actual requirements; do not weaken the receiver simply to make the proposed configuration connect.\nApplicability questions\n\nDoes the receiving input require TLS?\nWhich URI scheme and port does the proposed driver configuration select?\nDo the chosen options apply to that transport?\nWhere will the operator verify that the actual receiver retained the test message?\n\nDSE recommendation: agree the endpoint contract before deployment\nDSE recommends a short endpoint contract shared by the container and logging owners. Record the destination, scheme, port and transport-protection requirement from the receiver’s own configuration. Compare it with the driver’s documented limits before changing a workload definition.\nFor a TLS-only input, stop the direct GELF TCP proposal and identify a separately documented alternative with the responsible owners. Keep the original protection requirement in the decision. Do not add a plausible-looking protocol option or assume a reconnect setting supplies missing transport protection.\nReview selected driver options against the actual protocol. Keep TCP reconnection settings distinct from UDP compression settings. Record the approved configuration in the workload’s managed definition, with secret or environment data excluded from shared examples. Make the receiver identity and expected ingestion route reviewable without exposing sensitive connection material.\nDefine an ingestion check before calling the configuration operational. Choose a harmless marker and a destination-side observation that can identify that exact record. Pair the observation with workload and daemon diagnostics. Treat an unexplained absence as an unresolved delivery problem, even when the container itself appears healthy. Assign a recovery action without claiming that retry settings guarantee retention.\nVerification and evidence\nProposed verification, not performed: use a dedicated test workload and approved test input. First reconcile the configured receiver protocol with the endpoint contract. Do not send important operational records through an intentionally incompatible input as an experiment.\nGenerate a small numbered sequence of harmless messages and inspect the intended receiver for their identities and order. If a controlled connectivity interruption is approved, record reconnect observations separately from message continuity. Retain the selected transport, relevant options, daemon observations and received identifiers. Do not generalize one successful ingestion test into a guarantee of confidentiality or lossless delivery.\nOfficial references\n\nGraylog Extended Format logging driver — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T17:40:48+00:00", "dateModified": "2026-10-29T17:41:39+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Reject a TLS-only destination for Docker GELF TCP output" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 517, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Graylog Extended Format logging driver", "url": "https://docs.docker.com/engine/logging/drivers/gelf/" } } ] } }