Skip to content

feat: Add the org and space based certificates for syslog drains #1229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+49 −0
Open

feat: Add the org and space based certificates for syslog drains #1229

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions toc/rfc/rfc-draft-org-space-based-certificates-for-syslog-drains.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Meta
[meta]: #meta
- Name: Support Org- and Space-Based Certificates for Loggregator Syslog TLS/mTLS Drains
- Start Date: 2025-06-30
- Author(s): ZPascal
- Status: Draft
- RFC Pull Request: [community#1229](https://github.com/cloudfoundry/community/pull/1229)


## Summary

This RFC proposes to introduce support for **organization- and space-scoped client certificates** for Cloud Foundry Loggregator syslog drains using mutual TLS (mTLS), covering both **HTTPS** and **syslog+TLS** protocols. By issuing certificates at the org or space level instead of per application, this initiative will simplify certificate lifecycle management, enable centralized rotation, and facilitate integration with central certificate authorities. The change targets the reduction of operational overhead and the enhancement of tenant-level security.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding "By issuing certificates at the org or space level instead of per application". Do you mean for the syslog drain use case? The https://docs.cloudfoundry.org/devguide/deploy-apps/instance-identity.html feature is used in different use cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this is only for the certificates used for Syslog drains and has nothing to do with the instance identity certificates.


## Problem

Currently, Cloud Foundry syslog drains using mTLS rely on **application-specific client certificates**. This causes high operational overhead, especially in large environments, because:

- Certificates are tied to individual app instances and require frequent re-issuance.
- Rotating certificates across many apps is error-prone and challenging to coordinate.
- Managing a large number of app-level certificates leads to poor scalability and maintainability.

Without org/space-scoped certificates, operators struggle with scaling, secure rotation, and integration with enterprise PKI.

## Proposal

The following capabilities are proposed:

1. **Org/space-scoped certificate issuance**: When a syslog drain is created, the drain metadata will include the associated org and space. The Loggregator system must retrieve or generate a client certificate scoped to that org or space.
2. **Drain-level mTLS configuration**: The syslog adapter or HTTPS forwarder must use the org/space certificate when establishing mTLS connections to the remote drain endpoint.
3. **Centralized and automatic rotation support**: Certificates should be automatically renewed and reloaded with minimal or zero impact to traffic flow.
4. **Audit and visibility**: Logs and drain metadata must include the org/space identity used for certificate-based authentication.

### Example configuration

```bash
cf create-user-provided-service ORG-NAME -p '{"ca":"-----BEGIN CERTIFICATE-----\nMIIH...-----END CERTIFICATE-----"}'
```

or

```bash
cf create-user-provided-service SPACE-NAME -p '{"ca":"-----BEGIN CERTIFICATE-----\nMIIH...-----END CERTIFICATE-----", "cert":"-----BEGIN CERTIFICATE-----\nMIIH...-----END CERTIFICATE-----","key":"-----BEGIN PRIVATE KEY-----\nMIIE...-----END PRIVATE KEY-----"}'
```

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These example configurations show the creation of user provided service instances that happen to contain certificates. How does it relate to syslog drains as documented in https://docs.cloudfoundry.org/devguide/services/log-management.html ?

Can you provide a complete example that shows e.g. how multiple apps in a space use the same space-scope certificate for a syslog drain binding and maybe even how you would rotate it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephanme The call above will create credentials which have to be bound to the app. The problem with this approach is that these credentials are available to the app via the VCAP_SERVICES and will not be available to the Syslog Agent when creating the Syslog Drain. If this is accepted an app will have to somehow share the credentials with the Syslog Agent which will be hard to do as the Syslog Agent is a special kind of user provided service implemented as part of CF and not via an external service broker. An external broker could have collected all needed credentials and open a connection, but this is not the case.

### Configuration Flow

- When an app binds a syslog drain, the Cloud Controller should include org and space GUIDs in the drain metadata.
- The system retrieves a Certifacte Authority for that org or space from a binding.
- The drain connection must use this certificate for TLS/mTLS authentication.
Comment on lines +45 to +49
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add some words about the backwards compatibility of this flow with the current flow to create and consume a syslog drain.