RORDEV-1647 reverse proxy POC #81
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
…eproduction/RORDEV-1647 # Conflicts: # ror-demo-cluster/run.sh
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
# Conflicts: # ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml
…eproduction/RORDEV-1647
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (12)
ror-demo-cluster/conf/kbn-2/enterprise-ror-newplatform-kibana.yml (7)
9-9: [DUPLICATE] SSL verification disabled — acceptable for POC, but document production migration path.This setting was already flagged in a previous review. For isolated POC/dev environments, disabling SSL verification is acceptable, but this must not propagate to production. When graduating from POC, ensure a separate production config restores strict certificate validation (
fullorcertificate).Consider adding an inline comment to explicitly mark this as POC-only.
19-24: [DUPLICATE] Hard-coded Kibana encryption keys exposed in version control — must externalize.This issue was already flagged in a previous review and remains unresolved. The xpack encryption keys (lines 19, 20, 22) are identical hard-coded values committed to the repository. Anyone with repo access can use these to decrypt saved objects, reports, and sensitive configuration.
Externalize these values using Kibana's environment-variable interpolation (supported format:
${VAR}or${VAR:defaultValue}):-xpack.security.encryptionKey: "19+230i1902i310293213i109312i31209302193219039120i3j23h31h3h213h123!" -xpack.encryptedSavedObjects.encryptionKey: "19+230i1902i310293213i109312i31209302193219039120i3j23h31h3h213h123!" +xpack.security.encryptionKey: ${KBN_SECURITY_ENCRYPTION_KEY} +xpack.encryptedSavedObjects.encryptionKey: ${KBN_SAVED_OBJECTS_KEY}-xpack.reporting.encryptionKey: "19+230i1902i310293213i109312i31209302193219039120i3j23h31h3h213h123!" +xpack.reporting.encryptionKey: ${KBN_REPORTING_KEY}Then inject these at deployment time (Docker environment variables, Kubernetes Secrets, or Vault).
41-41: [DUPLICATE] Trace log level may expose sensitive data in logs — reduce for production.This issue was already flagged in a previous review. At
tracelevel, Kibana and ReadOnlyREST log detailed diagnostic output including request headers, session tokens, OIDC/SAML tokens, and user data. This risks exposing credentials or PII in logs that may persist to disk or log aggregation systems.For this POC, if trace logging is necessary for debugging, ensure:
- Logs are written to ephemeral storage only (not persisted to log archives)
- Log retention is short-lived (hours, not days)
- Before promoting to production or shared environments, reduce to
infoorwarn-readonlyrest_kbn.logLevel: trace +readonlyrest_kbn.logLevel: info
42-42: [DUPLICATE] Hard-coded ReadOnlyREST cookie secret exposed in version control.This issue was already flagged in a previous review and remains unresolved. The
cookiePassis a hard-coded 39-character secret in plain text. Anyone with repo access can forge or decrypt sessions.Externalize this using environment-variable interpolation:
-readonlyrest_kbn.cookiePass: '12312313123213123213123abcdefghijklm' +readonlyrest_kbn.cookiePass: ${ROR_COOKIE_PASS}Inject the environment variable at deployment time.
71-71: [DUPLICATE] Hard-coded ReadOnlyREST signature_key (500+ char API key) exposed in version control.This issue was already flagged in a previous review and remains unresolved. The
signature_keyis a large hard-coded API key committed to the repository. This key is used for inter-service authentication between the Kibana plugin and Elasticsearch ReadOnlyREST plugin. Exposure allows attackers to forge authentication tokens.Externalize this secret using Kibana environment-variable interpolation:
- signature_key: "9yzBfnLaTYLfGPzyKW9es76RKYhUVgmuv6ZtehaScj5msGpBpa5FWpwk295uJYaaffTFnQC5tsknh2AguVDaTrqCLfM5zCTqdE4UGNL73h28Bg4dPrvTAFQyygQqv4xfgnevBED6VZYdfjXAQLc8J8ywaHQQSmprZqYCWGE6sM3vzNUEWWB3kmGrEKa4sGbXhmXZCvL6NDnEJhXPDJAzu9BMQxn8CzVLqrx6BxDgPYF8gZCxtyxMckXwCaYXrxAGbjkYH69F4wYhuAdHSWgRAQCuWwYmWCA6g39j4VPge5pv962XYvxwJpvn23Y5KvNZ5S5c6crdG4f4gTCXnU36x92fKMQzsQV9K4phcuNvMWkpqVB6xMA5aPzUeHcGytD93dG8D52P5BxsgaJJE6QqDrk3Y2vyLw9ZEbJhPRJxbuBKVCBtVx26Ldd46dq5eyyzmNEyQGLrjQ4qd978VtG8TNT5rkn4ETJQEju5HfCBbjm3urGLFVqxhGVawecT4YM9Rry4EqXWkRJGTFQWQRnweUFbKNbVTC9NxcXEp6K5rSPEy9trb5UYLYhhMJ9fWSBMuenGRjNSJxeurMRCaxPpNppBLFnp8qW5ezfHgCBpEjkSNNzP4uXMZFAXmdUfJ8XQdPTWuYfdHYc5TZWnzrdq9wcfFQRDpDB2zX5Myu96krDt9vA7wNKfYwkSczA6qUQV66jA8nV4Cs38cDAKVBXnxz22ddAVrPv8ajpu7hgBtULMURjvLt94Nc5FDKw79CTTQxffWEj9BJCDCpQnTufmT8xenywwVJvtj49yv2MP2mGECrVDRmcGUAYBKR8G6ZnFAYDVC9UhY46FGWDcyVX3HKwgtHeb45Ww7dsW8JdMnZYctaEU585GZmqTJp2LcAWRcQPH25JewnPX8pjzVpJNcy7avfA2bcU86bfASvQBDUCrhjgRmK2ECR6vzPwTsYKRgFrDqb62FeMdrKgJ9vKs435T5ACN7MNtdRXHQ4fj5pNpUMDW26Wd7tt9bkBTqEGf" + signature_key: ${ROR_SIGNATURE_KEY}Ensure the environment variable is set at deployment time via Docker, Kubernetes Secrets, or your deployment tooling.
95-95: [DUPLICATE] Hard-coded OIDC Keycloak clientSecret exposed in version control.This issue was already flagged in a previous review and remains unresolved. The Keycloak OIDC
clientSecretis a hard-coded credential committed to the repository. Exposure allows attackers to impersonate the application and obtain tokens.Externalize this using Kibana environment-variable interpolation (compatible format:
${VAR}):- clientSecret: 'kibanasecret123' + clientSecret: ${OIDC_KEYCLOAK_CLIENT_SECRET}Inject the environment variable at deployment time.
110-110: [DUPLICATE] Hard-coded OIDC LemonLDAP clientSecret exposed in version control.This issue was already flagged in a previous review and remains unresolved. The LemonLDAP OIDC
clientSecretis a hard-coded credential (even if it appears to be a placeholder liketardis) committed to the repository.Externalize this using Kibana environment-variable interpolation:
- clientSecret: 'tardis' + clientSecret: ${OIDC_LEMONLDAP_CLIENT_SECRET}Inject the environment variable at deployment time.
ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml (5)
19-24: ❌ Hardcoded encryption keys must be externalized (duplicate of previous review).Lines 19–24 and line 22 commit Kibana encryption keys to source control. These secrets must be replaced with environment-variable placeholders and injected at deploy time.
Apply this diff:
-xpack.security.encryptionKey: "19+230i1902i310293213i109312i31209302193219039120i3j23h31h3h213h123!" -xpack.encryptedSavedObjects.encryptionKey: "19+230i1902i310293213i109312i31209302193219039120i3j23h31h3h213h123!" -xpack.reporting.encryptionKey: "19+230i1902i310293213i109312i31209302193219039120i3j23h31h3h213h123!" +xpack.security.encryptionKey: ${KBN_SECURITY_ENCRYPTION_KEY} +xpack.encryptedSavedObjects.encryptionKey: ${KBN_SAVED_OBJECTS_KEY} +xpack.reporting.encryptionKey: ${KBN_REPORTING_KEY}Also applies to: 22-22
71-71: ❌ Hardcodedsignature_keymust be externalized (duplicate of previous review).Line 71 commits a 1000+ character API signature key to source control, flagged by Gitleaks as a critical API key exposure. Replace with an environment variable reference.
- signature_key: "9yzBfnLaTYLfGPzyKW9es76RKYhUVgmuv6ZtehaScj5msGpBpa5FWpwk295uJYaaffTFnQC5tsknh2AguVDaTrqCLfM5zCTqdE4UGNL73h28Bg4dPrvTAFQyygQqv4xfgnevBED6VZYdfjXAQLc8J8ywaHQQSmprZqYCWGE6sM3vzNUEWWB3kmGrEKa4sGbXhmXZCvL6NDnEJhXPDJAzu9BMQxn8CzVLqrx6BxDgPYF8gZCxtyxMckXwCaYXrxAGbjkYH69F4wYhuAdHSWgRAQCuWwYmWCA6g39j4VPge5pv962XYvxwJpvn23Y5KvNZ5S5c6crdG4f4gTCXnU36x92fKMQzsQV9K4phcuNvMWkpqVB6xMA5aPzUeHcGytD93dG8D52P5BxsgaJJE6QqDrk3Y2vyLw9ZEbJhPRJxbuBKVCBtVx26Ldd46dq5eyyzmNEyQGLrjQ4qd978VtG8TNT5rkn4ETJQEju5HfCBbjm3urGLFVqxhGVawecT4YM9Rry4EqXWkRJGTFQWQRnweUFbKNbVTC9NxcXEp6K5rSPEy9trb5UYLYhhMJ9fWSBMuenGRjNSJxeurMRCaxPpNppBLFnp8qW5ezfHgCBpEjkSNNzP4uXMZFAXmdUfJ8XQdPTWuYfdHYc5TZWnzrdq9wcfFQRDpDB2zX5Myu96krDt9vA7wNKfYwkSczA6qUQV66jA8nV4Cs38cDAKVBXnxz22ddAVrPv8ajpu7hgBtULMURjvLt94Nc5FDKw79CTTQxffWEj9BJCDCpQnTufmT8xenywwVJvtj49yv2MP2mGECrVDRmcGUAYBKR8G6ZnFAYDVC9UhY46FGWDcyVX3HKwgtHeb45Ww7dsW8JdMnZYctaEU585GZmqTJp2LcAWRcQPH25JewnPX8pjzVpJNcy7avfA2bcU86bfASvQBDUCrhjgRmK2ECR6vzPwTsYKRgFrDqb62FeMdrKgJ9vKs435T5ACN7MNtdRXHQ4fj5pNpUMDW26Wd7tt9bkBTqEGf" + signature_key: ${ROR_SIGNATURE_KEY}
95-95: ❌ Hardcoded OIDCclientSecretvalues must be externalized (duplicate of previous review).Lines 95 and 110 commit plaintext OIDC client secrets (
kibanasecret123andtardis) to source control. These credentials allow impersonation of the Kibana application to identity providers.clientID: 'ror-oidc' - clientSecret: 'kibanasecret123' + clientSecret: ${KEYCLOAK_CLIENT_SECRET}clientID: 'private' - clientSecret: 'tardis' + clientSecret: ${LEMONLDAP_CLIENT_SECRET}Also applies to: 110-110
89-93:⚠️ Keycloak OIDC endpoints use HTTP instead of HTTPS (duplicate of previous review).Lines 89–93 and 100 reference Keycloak endpoints over HTTP (
http://kc.localhost:8080). This creates a downgrade vulnerability during the OIDC authentication flow, allowing potential token interception.Use HTTPS for all external authentication endpoints:
- issuer: 'http://kc.localhost:8080/realms/ror' - authorizationURL: 'http://kc.localhost:8080/realms/ror/protocol/openid-connect/auth' - tokenURL: 'http://kc.localhost:8080/realms/ror/protocol/openid-connect/token' - userInfoURL: 'http://kc.localhost:8080/realms/ror/protocol/openid-connect/userinfo' - jwksURL: 'http://kc.localhost:8080/realms/ror/protocol/openid-connect/certs' + issuer: 'https://kc.localhost:8080/realms/ror' + authorizationURL: 'https://kc.localhost:8080/realms/ror/protocol/openid-connect/auth' + tokenURL: 'https://kc.localhost:8080/realms/ror/protocol/openid-connect/token' + userInfoURL: 'https://kc.localhost:8080/realms/ror/protocol/openid-connect/userinfo' + jwksURL: 'https://kc.localhost:8080/realms/ror/protocol/openid-connect/certs' - logoutUrl: 'http://kc.localhost:8080/realms/ror/protocol/openid-connect/logout' + logoutUrl: 'https://kc.localhost:8080/realms/ror/protocol/openid-connect/logout'Also applies to: 100-100
99-99: ❌ Fix thekibanaExternalHostinconsistency between OIDC providers (duplicate of previous review).Line 99 configures
kibanaExternalHost: 'localhost:8443'for Keycloak OIDC, but line 114 uses the same value for LemonLDAP. Since Kibana is configured withserver.basePath: /deva-notix(line 3), both OIDC provider redirects must include the base path, otherwise OIDC redirects will fail.usernameParameter: 'preferred_username' groupsParameter: 'groups' - kibanaExternalHost: 'localhost:8443' + kibanaExternalHost: 'localhost:8443/deva-notix' logoutUrl: 'http://kc.localhost:8080/realms/ror/protocol/openid-connect/logout'Also applies to: 114-114
🧹 Nitpick comments (2)
ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml (1)
10-10: XSRF allowlist should be configured with trusted URIs.For production deployments, populate
server.xsrf.allowlistwith specific trusted origins/paths that require CSRF exemption (e.g., OIDC/SAML callback endpoints). An empty allowlist is acceptable for this POC but should be addressed before production use.ror-demo-cluster/conf/keycloak/ror-realm.json (1)
108-108: Consider restricting OIDC post.logout.redirect.uris for production.The wildcard pattern
https://localhost:8443/*is overly permissive. For production, restrict this to specific trusted paths, such ashttps://localhost:8443/deva-notixto match your Kibana basePath configuration.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
ror-demo-cluster/conf/es/readonlyrest.yml(1 hunks)ror-demo-cluster/conf/kbn-2/enterprise-ror-newplatform-kibana.yml(1 hunks)ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml(2 hunks)ror-demo-cluster/conf/keycloak/ror-realm.json(5 hunks)
🔇 Additional comments (6)
ror-demo-cluster/conf/es/readonlyrest.yml (1)
65-72: ✓ Group mapping alignment is correct.The updated external_group_ids restricts EndUsers to specifically the "extEndUsers" group, and the new BusinessUsers mapping correctly adds support for "extBusinessUsers". These changes align with the expanded groups in the Keycloak realm and support the multi-provider authentication model in this POC.
ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml (1)
3-5: ✓ Reverse proxy basePath configuration is appropriate.The basePath, rewriteBasePath, and publicBaseUrl settings are correctly configured for the reverse proxy POC setup. The /deva-notix path matches the test URL structure from the PR objectives.
ror-demo-cluster/conf/keycloak/ror-realm.json (4)
25-25: ✓ SAML client URLs correctly updated for reverse proxy POC.All SAML assertion consumer URLs and admin URLs have been properly updated from the old localhost:15601 to the new reverse proxy endpoint
localhost:8443/deva-notix. The path and protocol are consistent across all endpoints.Also applies to: 47-47, 50-50, 52-52
66-95: ✓ Protocol mapper configuration correctly implements group membership mapping.The migration from saml-user-property-mapper to saml-group-membership-mapper is appropriate for group-based access control. The configuration correctly specifies group attributes, and the addition of defaultClientScopes and optionalClientScopes provides proper scope management for the SAML client.
128-146: ✓ Group definitions are consistent and properly structured.The expanded groups (extEndUsers and extBusinessUsers) align with the external_group_ids defined in the ReadonlyREST configuration. Group attributes and realm roles are properly configured to support group-based access control across the authentication providers.
154-155: ✓ User group assignments support proper testing of multiple access levels.The user configurations correctly assign extUser1 to both extEndUsers and extBusinessUsers groups (enabling multi-role testing), while extUser2 has only extEndUsers access. Realm role assignments mirror group assignments for consistency.
Also applies to: 163-163
2 participants
ror-demo-clusterand run./run.shhttps://localhost:8443/deva-notixa) enter credentials
admin:adminin the login form to log in as local userb) click "Keycloak OIDC" and log in as
extUser1:extUser1c) click "LemonLDAP OpenID" and log in as
dwho:dwhoSummary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.