Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
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
2 changes: 1 addition & 1 deletion ror-demo-cluster/clean.sh
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
#!/bin/bash -e

docker compose rm --stop --force
docker compose --profile ENT --profile PRO --profile FREE rm --stop --force
11 changes: 11 additions & 0 deletions ror-demo-cluster/conf/es/readonlyrest.yml
Original file line number Diff line number Diff line change
Expand Up @@ -56,3 +56,14 @@ readonlyrest:
groups:
- id: "EndUsers"
name: "End Users"

- username: "*"
ror_kbn_authentication:
name: "kbn1"
groups:
- id: "EndUsers"
name: "End Users"
Comment on lines +60 to +65
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Wildcard user mapping is extremely permissive.

The username "*" matches any user authenticated via KBN, granting all of them EndUsers group access. In a production environment, this eliminates access control granularity and could allow unintended users to access sensitive data.

For a demo/sandbox, this may be acceptable for ease of testing, but document this permissive behavior clearly and ensure it's never used in production deployments.

Consider whether this wildcard mapping aligns with the intended security model for this PR. If the goal is to test Keycloak/OIDC flows with minimal friction, this is understandable. Otherwise, consider replacing the wildcard with explicit user entries or group-based matching.


🏁 Script executed:

#!/bin/bash
file=$(fd readonlyrest.yml)
echo "File found: $file"
echo -e "\nLines 50–90:"
sed -n '50,90p' "$file"
echo -e "\nOccurrences of 'signature_key':"
grep -n 'signature_key' "$file"

Length of output: 419


🏁 Script executed:

#!/bin/bash
echo "Searching for wildcard username snippet..."
rg -n "username:\s*\"\\*\"" -t yaml

echo -e "\nContext around wildcard username:"
rg -n -C5 "username:\s*\"\\*\"" -t yaml

echo -e "\nSearching for signature_key occurrences..."
rg -n "signature_key" -t yaml

echo -e "\nContext around signature_key:"
rg -n -C5 "signature_key" -t yaml

Length of output: 6573


Restrict wildcard user mapping in ror-demo-cluster/conf/es/readonlyrest.yml (lines 60–65). The username "*" matches all KBN-authenticated users, granting them EndUsers access; replace with explicit usernames or group patterns and ensure this demo-only setting is documented or removed in production deployments.

🤖 Prompt for AI Agents
In ror-demo-cluster/conf/es/readonlyrest.yml around lines 60–65, the username
field is set to "*" which maps all KBN-authenticated users to the EndUsers
group; replace the wildcard with explicit usernames or a restrictive group/regex
pattern (e.g., a curated list of demo accounts or a specific allowed pattern),
update the groups mapping accordingly, and add a comment in the file noting this
is a demo-only configuration (or remove it entirely for production) so that
broad access is not granted in non-demo deployments.


ror_kbn:
- name: kbn1
signature_key: "9yzBfnLaTYLfGPzyKW9es76RKYhUVgmuv6ZtehaScj5msGpBpa5FWpwk295uJYaaffTFnQC5tsknh2AguVDaTrqCLfM5zCTqdE4UGNL73h28Bg4dPrvTAFQyygQqv4xfgnevBED6VZYdfjXAQLc8J8ywaHQQSmprZqYCWGE6sM3vzNUEWWB3kmGrEKa4sGbXhmXZCvL6NDnEJhXPDJAzu9BMQxn8CzVLqrx6BxDgPYF8gZCxtyxMckXwCaYXrxAGbjkYH69F4wYhuAdHSWgRAQCuWwYmWCA6g39j4VPge5pv962XYvxwJpvn23Y5KvNZ5S5c6crdG4f4gTCXnU36x92fKMQzsQV9K4phcuNvMWkpqVB6xMA5aPzUeHcGytD93dG8D52P5BxsgaJJE6QqDrk3Y2vyLw9ZEbJhPRJxbuBKVCBtVx26Ldd46dq5eyyzmNEyQGLrjQ4qd978VtG8TNT5rkn4ETJQEju5HfCBbjm3urGLFVqxhGVawecT4YM9Rry4EqXWkRJGTFQWQRnweUFbKNbVTC9NxcXEp6K5rSPEy9trb5UYLYhhMJ9fWSBMuenGRjNSJxeurMRCaxPpNppBLFnp8qW5ezfHgCBpEjkSNNzP4uXMZFAXmdUfJ8XQdPTWuYfdHYc5TZWnzrdq9wcfFQRDpDB2zX5Myu96krDt9vA7wNKfYwkSczA6qUQV66jA8nV4Cs38cDAKVBXnxz22ddAVrPv8ajpu7hgBtULMURjvLt94Nc5FDKw79CTTQxffWEj9BJCDCpQnTufmT8xenywwVJvtj49yv2MP2mGECrVDRmcGUAYBKR8G6ZnFAYDVC9UhY46FGWDcyVX3HKwgtHeb45Ww7dsW8JdMnZYctaEU585GZmqTJp2LcAWRcQPH25JewnPX8pjzVpJNcy7avfA2bcU86bfASvQBDUCrhjgRmK2ECR6vzPwTsYKRgFrDqb62FeMdrKgJ9vKs435T5ACN7MNtdRXHQ4fj5pNpUMDW26Wd7tt9bkBTqEGf"
Comment on lines +67 to +69
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Hardcoded signature key is flagged by static analysis.

Gitleaks correctly identifies the signature_key as a high-severity credential. In a demo/sandbox context, this is acceptable for local testing, but this key should never be committed to production repositories.

For production deployments:

  • Generate the signature key at deployment time
  • Store it in a secrets management system (e.g., Vault, AWS Secrets Manager, Kubernetes Secrets)
  • Rotate it regularly
  • Never commit it to version control

Since this appears to be a demo configuration (based on the PR context), consider adding a comment above the key indicating it's for testing only:

  ror_kbn:
    - name: kbn1
+      # DEMO KEY ONLY - generate a unique key for production deployments
      signature_key: "9yzBfnLaTYLfGPzyKW9es76RKYhUVgmuv6ZtehaScj5msGpBpa5FWpwk295uJYaaffTFnQC5tsknh2AguVDaTrqCLfM5zCTqdE4UGNL73h28Bg4dPrvTAFQyygQqv4xfgnevBED6VZYdfjXAQLc8J8ywaHQQSmprZqYCWGE6sM3vzNUEWWB3kmGrEKa4sGbXhmXZCvL6NDnEJhXPDJAzu9BMQxn8CzVLqrx6BxDgPYF8gZCxtyxMckXwCaYXrxAGbjkYH69F4wYhuAdHSWgRAQCuWwYmWCA6g39j4VPge5pv962XYvxwJpvn23Y5KvNZ5S5c6crdG4f4gTCXnU36x92fKMQzsQV9K4phcuNvMWkpqVB6xMA5aPzUeHcGytD93dG8D52P5BxsgaJJE6QqDrk3Y2vyLw9ZEbJhPRJxbuBKVCBtVx26Ldd46dq5eyyzmNEyQGLrjQ4qd978VtG8TNT5rkn4ETJQEju5HfCBbjm3urGLFVqxhGVawecT4YM9Rry4EqXWkRJGTFQWQRnweUFbKNbVTC9NxcXEp6K5rSPEy9trb5UYLYhhMJ9fWSBMuenGRjNSJxeurMRCaxPpNppBLFnp8qW5ezfHgCBpEjkSNNzP4uXMZFAXmdUfJ8XQdPTWuYfdHYc5TZWnzrdq9wcfFQRDpDB2zX5Myu96krDt9vA7wNKfYwkSczA6qUQV66jA8nV4Cs38cDAKVBXnxz22ddAVrPv8ajpu7hgBtULMURjvLt94Nc5FDKw79CTTQxffWEj9BJCDCpQnTufmT8xenywwVJvtj49yv2MP2mGECrVDRmcGUAYBKR8G6ZnFAYDVC9UhY46FGWDcyVX3HKwgtHeb45Ww7dsW8JdMnZYctaEU585GZmqTJp2LcAWRcQPH25JewnPX8pjzVpJNcy7avfA2bcU86bfASvQBDUCrhjgRmK2ECR6vzPwTsYKRgFrDqb62FeMdrKgJ9vKs435T5ACN7MNtdRXHQ4fj5pNUMDW26Wd7tt9bkBTqEGf"
🧰 Tools
🪛 Gitleaks (8.28.0)

[high] 69-69: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

🤖 Prompt for AI Agents
In ror-demo-cluster/conf/es/readonlyrest.yml around lines 67-69, the long
hardcoded signature_key is a high-severity secret that must not be committed;
remove the literal value and replace it with a reference to a runtime secret
(e.g., use an environment variable or secrets mount such as ${SIGNATURE_KEY} or
a Kubernetes secret) and add a single-line comment above indicating this entry
is demo-only and must be generated at deployment time and stored in a secrets
manager; ensure deployment docs/scripts generate or inject the key and do not
embed it in source control.

52 changes: 52 additions & 0 deletions ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
server.name: kibana-ror
server.host: 0.0.0.0

elasticsearch.username: kibana
elasticsearch.password: kibana
elasticsearch.ssl.verificationMode: none

# generated with:
# $ openssl req -x509 -batch -nodes -days 3650 -newkey rsa:2048 -keyout kibana.key -out kibana.crt
server.ssl.enabled: true
server.ssl.certificate: /usr/share/kibana/config/kibana.crt
server.ssl.key: /usr/share/kibana/config/kibana.key
server.ssl.redirectHttpFromPort: 80

readonlyrest_kbn.logLevel: info
readonlyrest_kbn.cookiePass: '12312313123213123213123abcdefghijklm'
readonlyrest_kbn:
auth:
signature_key: "9yzBfnLaTYLfGPzyKW9es76RKYhUVgmuv6ZtehaScj5msGpBpa5FWpwk295uJYaaffTFnQC5tsknh2AguVDaTrqCLfM5zCTqdE4UGNL73h28Bg4dPrvTAFQyygQqv4xfgnevBED6VZYdfjXAQLc8J8ywaHQQSmprZqYCWGE6sM3vzNUEWWB3kmGrEKa4sGbXhmXZCvL6NDnEJhXPDJAzu9BMQxn8CzVLqrx6BxDgPYF8gZCxtyxMckXwCaYXrxAGbjkYH69F4wYhuAdHSWgRAQCuWwYmWCA6g39j4VPge5pv962XYvxwJpvn23Y5KvNZ5S5c6crdG4f4gTCXnU36x92fKMQzsQV9K4phcuNvMWkpqVB6xMA5aPzUeHcGytD93dG8D52P5BxsgaJJE6QqDrk3Y2vyLw9ZEbJhPRJxbuBKVCBtVx26Ldd46dq5eyyzmNEyQGLrjQ4qd978VtG8TNT5rkn4ETJQEju5HfCBbjm3urGLFVqxhGVawecT4YM9Rry4EqXWkRJGTFQWQRnweUFbKNbVTC9NxcXEp6K5rSPEy9trb5UYLYhhMJ9fWSBMuenGRjNSJxeurMRCaxPpNppBLFnp8qW5ezfHgCBpEjkSNNzP4uXMZFAXmdUfJ8XQdPTWuYfdHYc5TZWnzrdq9wcfFQRDpDB2zX5Myu96krDt9vA7wNKfYwkSczA6qUQV66jA8nV4Cs38cDAKVBXnxz22ddAVrPv8ajpu7hgBtULMURjvLt94Nc5FDKw79CTTQxffWEj9BJCDCpQnTufmT8xenywwVJvtj49yv2MP2mGECrVDRmcGUAYBKR8G6ZnFAYDVC9UhY46FGWDcyVX3HKwgtHeb45Ww7dsW8JdMnZYctaEU585GZmqTJp2LcAWRcQPH25JewnPX8pjzVpJNcy7avfA2bcU86bfASvQBDUCrhjgRmK2ECR6vzPwTsYKRgFrDqb62FeMdrKgJ9vKs435T5ACN7MNtdRXHQ4fj5pNpUMDW26Wd7tt9bkBTqEGf"

Comment on lines +15 to +20
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Do not commit hard-coded signing secrets

readonlyrest_kbn.cookiePass and the long signature_key are high-entropy secrets now stored in git. Gitleaks already flags them, and anyone with repo access can forge cookies or signatures for this environment. Please externalize these values (e.g., env vars or mounted secrets) or replace them with non-sensitive placeholders. (Based on static analysis)

🧰 Tools
🪛 Gitleaks (8.28.0)

[high] 19-19: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

🤖 Prompt for AI Agents
In ror-demo-cluster/conf/kbn/enterprise-ror-newplatform-kibana.yml around lines
15-20, the cookiePass and signature_key are hard-coded high-entropy secrets;
remove these literal values and replace them with references to externalized
secrets (environment variables or mounted secret files) and non-sensitive
placeholders in the committed file, update any startup/config docs or deployment
manifests to inject the real secrets at runtime, and ensure you rotate the
exposed secrets and run gitleaks/scan to verify removal before committing.

oidc_keycloak:
buttonName: "Keycloak OIDC"
type: "oidc"
protocol: "https"
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'
clientID: 'kibana-ror'
clientSecret: 'kibanasecret123'
scope: 'openid profile email'
usernameParameter: 'preferred_username'
groupsParameter: 'groups'
kibanaExternalHost: 'localhost:15601'
logoutUrl: 'http://kc.localhost:8080/realms/ror/protocol/openid-connect/logout'
oidc_lemon_ldap:
buttonName: "LemonLDAP OpenID"
type: "oidc"
protocol: "https"
issuer: 'https://oidctest.wsweet.org/'
authorizationURL: 'https://oidctest.wsweet.org/oauth2/authorize'
tokenURL: 'https://oidctest.wsweet.org/oauth2/token'
userInfoURL: 'https://oidctest.wsweet.org/oauth2/userinfo'
clientID: 'private'
clientSecret: 'tardis'
scope: 'openid users roles'
usernameParameter: 'sub'
groupsParameter: 'roles'
kibanaExternalHost: 'localhost:15601'
logoutUrl: 'https://oidctest.wsweet.org/oauth2/logout'
jwksURL: 'https://oidctest.wsweet.org/oauth2/jwks'
16 changes: 16 additions & 0 deletions ror-demo-cluster/conf/kbn/pro-ror-newplatform-kibana.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
server.name: kibana-ror
server.host: 0.0.0.0

elasticsearch.username: kibana
elasticsearch.password: kibana
elasticsearch.ssl.verificationMode: none
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

SSL verification is disabled.

Setting elasticsearch.ssl.verificationMode: none disables certificate validation, making the connection vulnerable to man-in-the-middle attacks. In a production environment, this would allow an attacker to intercept credentials and data between Kibana and Elasticsearch.

For a demo/sandbox, this may be acceptable to simplify local setup. However, ensure this configuration is never used in production. Consider adding a comment to make the risk explicit:

 elasticsearch.username: kibana
 elasticsearch.password: kibana
+# DEMO ONLY - disable SSL verification for local development
+# In production, use verificationMode: full and provide a valid CA certificate
 elasticsearch.ssl.verificationMode: none
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
elasticsearch.ssl.verificationMode: none
elasticsearch.username: kibana
elasticsearch.password: kibana
# DEMO ONLY – disable SSL verification for local development
# In production, use verificationMode: full and provide a valid CA certificate
elasticsearch.ssl.verificationMode: none
🤖 Prompt for AI Agents
In ror-demo-cluster/conf/kbn/pro-ror-newplatform-kibana.yml around line 6, the
setting `elasticsearch.ssl.verificationMode: none` disables TLS certificate
validation and must not be used in production; change it to enforce validation
(e.g., `full`), configure the Elasticsearch CA/certificates and any client certs
needed, or use a separate demo-only config guarded by an environment flag, and
add a clear comment above the setting stating this is allowed only for
local/demo use and must be removed or replaced with validated TLS settings in
production.


# generated with:
# $ openssl req -x509 -batch -nodes -days 3650 -newkey rsa:2048 -keyout kibana.key -out kibana.crt
server.ssl.enabled: true
server.ssl.certificate: /usr/share/kibana/config/kibana.crt
server.ssl.key: /usr/share/kibana/config/kibana.key
server.ssl.redirectHttpFromPort: 80

readonlyrest_kbn.logLevel: info
readonlyrest_kbn.cookiePass: '12312313123213123213123abcdefghijklm'
Comment on lines +15 to +16
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Hardcoded session cookie secret.

The cookiePass is a static string hardcoded in the configuration. In production, an attacker who obtains this value could forge session cookies and impersonate users.

For production deployments:

  • Generate a strong, random cookiePass at deployment time (minimum 32 characters)
  • Store it securely (secrets manager, environment variable from secure source)
  • Rotate it periodically

For a demo configuration, consider adding a warning comment:

 readonlyrest_kbn.logLevel: info
+# DEMO ONLY - use a randomly generated secret in production
 readonlyrest_kbn.cookiePass: '12312313123213123213123abcdefghijklm'

58 changes: 58 additions & 0 deletions ror-demo-cluster/conf/keycloak/ror-realm.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
{
"realm": "ror",
"enabled": true,
"clients": [
{
"clientId": "kibana-ror",
"enabled": true,
"protocol": "openid-connect",
"publicClient": false,
"secret": "kibanasecret123",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Hardcoded client secret is flagged by static analysis.

Gitleaks correctly identifies "secret": "kibanasecret123" as a high-severity credential. In production, an attacker with this secret could impersonate the Kibana client and obtain access tokens for any user.

For production:

  • Generate a strong, random client secret (use openssl rand -base64 32 or similar)
  • Store it in a secrets manager
  • Configure both Keycloak and Kibana to read it from secure storage
  • Never commit it to version control

For this demo configuration, consider adding a comment in the JSON (if the realm import supports it) or in adjacent documentation warning that this is a demo-only secret.

🧰 Tools
🪛 Gitleaks (8.28.0)

[high] 10-10: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

🤖 Prompt for AI Agents
In ror-demo-cluster/conf/keycloak/ror-realm.json around line 10, the client
secret is hardcoded ("secret": "kibanasecret123"); remove the literal value from
the committed JSON and instead reference a secret fetched at runtime (e.g.,
environment variable or secrets manager) so Keycloak is configured with the
secret externally, generate a strong random secret for production (openssl rand
-base64 32), store it in your secrets manager and configure both Keycloak and
Kibana to read it from that store, and for this demo-only repo add an adjacent
README or comment (outside committed JSON if JSON import doesn't support
comments) explicitly stating the string is a demo secret and must be replaced in
production.

"redirectUris": ["*"],
"webOrigins": ["*"],
Comment on lines +11 to +12
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Wildcard redirect URIs and web origins are insecure.

Setting "redirectUris": ["*"] and "webOrigins": ["*"] disables critical OAuth security protections:

  1. Open redirect vulnerability: An attacker can trick users into authorizing their malicious application by redirecting the OAuth flow to an attacker-controlled domain.
  2. CORS bypass: Any origin can make authenticated requests to the Keycloak endpoints, potentially leaking tokens.

For production, replace wildcards with explicit allowed values:

"redirectUris": ["https://localhost:15601/*", "https://yourdomain.com/*"],
"webOrigins": ["https://localhost:15601", "https://yourdomain.com"]

For a demo/sandbox environment, if this is intentional for local testing flexibility, consider adding documentation that explains this configuration should never reach production.

🤖 Prompt for AI Agents
In ror-demo-cluster/conf/keycloak/ror-realm.json around lines 11 to 12, the
configuration currently uses wildcard values for "redirectUris" and
"webOrigins", which is insecure; replace these wildcards with explicit,
environment-specific origins and redirect URIs (e.g., fully qualified
https://localhost:PORT/* and your production domain patterns) and remove "*"
entries, and if this wildcard setting is intentionally used only for local/demo
testing, add a clear comment or documentation in the repo stating this is for
non-production use only and must not be deployed to production.

"attributes": {
"post.logout.redirect.uris": "https://localhost:15601/*"
},
"protocolMappers": [
{
"name": "groups",
"protocol": "openid-connect",
"protocolMapper": "oidc-group-membership-mapper",
"consentRequired": false,
"config": {
"full.path": "false",
"access.token.claim": "true",
"id.token.claim": "true",
"userinfo.token.claim": "true",
"claim.name": "groups",
"jsonType.label": "String"
}
}
]
}
],
"groups": [
{"name": "extEndUsers"}
],
"users": [
{
"username": "extUser1",
"enabled": true,
"emailVerified": true,
"credentials": [ { "type": "password", "value": "extUser1", "temporary": false } ],
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Plaintext passwords in realm configuration.

The credentials are stored in plaintext in the realm export (e.g., "value": "extUser1"). While this is standard for Keycloak realm imports during development, it poses a risk if:

  • This file is committed to a public repository
  • The same passwords are reused in production

Best practices:

  • Use distinct, random passwords for each demo environment
  • Document clearly that these are demo-only credentials
  • Never reuse these passwords in production systems
  • Consider using Keycloak's user federation or external identity providers in production rather than managing passwords directly

For a demo/sandbox, this is acceptable, but ensure the PR description or README clearly states these are testing credentials only.

Also applies to: 50-50

🤖 Prompt for AI Agents
In ror-demo-cluster/conf/keycloak/ror-realm.json around line 42, the realm
export contains a plaintext user password ("value": "extUser1"); remove or
replace the hardcoded cleartext credential and treat it as demo-only: either
remove the credentials entry and provision test passwords at deployment time
(via a script or environment-secured secret injection), or replace the value
with a clearly marked placeholder (e.g., "<DEMO_PASSWORD>" or a reference to a
secret name); update the PR description and repo README to state these are
demo-only credentials and never to be reused in production, and optionally add a
small provisioning script that generates random passwords for demo environments.

"groups": ["extEndUsers"],
"realmRoles": ["offline_access", "uma_authorization"]
},
{
"username": "extUser2",
"enabled": true,
"emailVerified": true,
"credentials": [ { "type": "password", "value": "extUser2", "temporary": false } ],
"groups": ["extEndUsers"],
"realmRoles": ["offline_access", "uma_authorization"]
}
],
"defaultDefaultClientScopes": ["web-origins", "role_list", "profile", "roles", "email"],
"defaultOptionalClientScopes": ["address", "phone", "offline_access"]
}

27 changes: 27 additions & 0 deletions ror-demo-cluster/docker-compose.yml
Original file line number Diff line number Diff line change
@@ -1,4 +1,27 @@
services:
# Enterprise-only service
keycloak:
image: quay.io/keycloak/keycloak:20.0.5
profiles: ["ENT"]
environment:
- KEYCLOAK_ADMIN=admin
- KEYCLOAK_ADMIN_PASSWORD=admin
- KEYCLOAK_FRONTEND_URL=http://kc.localhost:8080
volumes:
- ./conf/keycloak/ror-realm.json:/opt/keycloak/data/import/ror-realm.json:ro
command: ["start-dev", "--import-realm", "--hostname=kc.localhost", "--http-enabled=true", "--http-port=8080"]
ports:
- "8080:8080"
healthcheck:
test: ["CMD-SHELL", "curl -fksS --connect-timeout 3 --max-time 5 --retry 5 --retry-connrefused http://127.0.0.1:8080/realms/ror/.well-known/openid-configuration >/dev/null || exit 1"]
interval: 10s
timeout: 10s
retries: 30
start_period: 40s
networks:
es-ror-network:
aliases:
- kc.localhost

es-ror:
build:
Expand Down Expand Up @@ -40,9 +63,13 @@ services:
KBN_VERSION: ${KBN_VERSION:-KBN_VERSION_NOT_CONFIGURED}
ROR_VERSION: ${ROR_KBN_VERSION:-ROR_KBN_VERSION_NOT_CONFIGURED}
ROR_FILE: ${KBN_ROR_FILE:-KBN_ROR_FILE_NOT_CONFIGURED}
ROR_LICENSE_EDITION: ${ROR_LICENSE_EDITION:-ROR_LICENSE_EDITION_NOT_CONFIGURED}
depends_on:
es-ror:
condition: service_healthy
keycloak:
condition: service_healthy
required: false
ports:
- "15601:5601"
environment:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,12 @@ FROM docker.elastic.co/kibana/kibana:${KBN_VERSION}

ARG KBN_VERSION=please_set_kbn_version_arg
ARG ROR_VERSION=please_set_ror_version_arg
ARG ROR_LICENSE_EDITION=please_set_ror_license_edition_arg

COPY conf/kbn/ror-newplatform-kibana.yml /usr/share/kibana/config/ror-newplatform-kibana.yml
COPY conf/kbn/ror-oldplatform-kibana.yml /usr/share/kibana/config/ror-oldplatform-kibana.yml
COPY conf/kbn/enterprise-ror-newplatform-kibana.yml /usr/share/kibana/config/enterprise-ror-newplatform-kibana.yml
COPY conf/kbn/pro-ror-newplatform-kibana.yml /usr/share/kibana/config/pro-ror-newplatform-kibana.yml
COPY conf/kbn/free-ror-newplatform-kibana.yml /usr/share/kibana/config/free-ror-newplatform-kibana.yml
COPY conf/kbn/kibana.crt /usr/share/kibana/config/kibana.crt
COPY conf/kbn/kibana.key /usr/share/kibana/config/kibana.key
COPY images/kbn/install-ror-kbn-using-api.sh /tmp/install-ror.sh
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,12 @@ FROM docker.elastic.co/kibana/kibana:${KBN_VERSION}

ARG KBN_VERSION=please_set_kbn_version_arg
ARG ROR_FILE=please_set_ror_file_path
ARG ROR_LICENSE_EDITION=please_set_ror_license_edition_arg

COPY conf/kbn/ror-newplatform-kibana.yml /usr/share/kibana/config/ror-newplatform-kibana.yml
COPY conf/kbn/ror-oldplatform-kibana.yml /usr/share/kibana/config/ror-oldplatform-kibana.yml
COPY conf/kbn/enterprise-ror-newplatform-kibana.yml /usr/share/kibana/config/enterprise-ror-newplatform-kibana.yml
COPY conf/kbn/pro-ror-newplatform-kibana.yml /usr/share/kibana/config/pro-ror-newplatform-kibana.yml
COPY conf/kbn/free-ror-newplatform-kibana.yml /usr/share/kibana/config/free-ror-newplatform-kibana.yml
COPY conf/kbn/kibana.crt /usr/share/kibana/config/kibana.crt
COPY conf/kbn/kibana.key /usr/share/kibana/config/kibana.key
COPY images/kbn/install-ror-kbn-using-file.sh /tmp/install-ror.sh
Expand Down
34 changes: 27 additions & 7 deletions ror-demo-cluster/images/kbn/install-ror-kbn-using-api.sh
Original file line number Diff line number Diff line change
Expand Up @@ -43,12 +43,32 @@ elif greater_than_or_equal "$KBN_VERSION" "7.9.0" ; then
/usr/share/kibana/node/bin/node plugins/readonlyrestkbn/ror-tools.js patch --I_UNDERSTAND_AND_ACCEPT_KBN_PATCHING=yes
fi

if greater_than_or_equal "$KBN_VERSION" "7.9.0"; then
mv /usr/share/kibana/config/ror-newplatform-kibana.yml /usr/share/kibana/config/kibana.yml
else
mv /usr/share/kibana/config/ror-oldplatform-kibana.yml /usr/share/kibana/config/kibana.yml
rm -rf /usr/share/kibana/optimize # for some reason we have to remove it and let kibana optimize it on startup
fi
if greater_than_or_equal "$KBN_VERSION" "7.9.0"; then
case "${ROR_LICENSE_EDITION:-}" in
ENT)
mv /usr/share/kibana/config/enterprise-ror-newplatform-kibana.yml \
/usr/share/kibana/config/kibana.yml
;;
PRO)
mv /usr/share/kibana/config/pro-ror-newplatform-kibana.yml \
/usr/share/kibana/config/kibana.yml
;;
FREE)
mv /usr/share/kibana/config/free-ror-newplatform-kibana.yml \
/usr/share/kibana/config/kibana.yml
;;
"")
echo "ERROR: ROR_LICENSE_EDITION is not set" >&2
exit 1
;;
*)
echo "ERROR: Unsupported ROR_LICENSE_EDITION='${ROR_LICENSE_EDITION}'" >&2
exit 2
;;
esac
else
mv /usr/share/kibana/config/ror-oldplatform-kibana.yml /usr/share/kibana/config/kibana.yml
rm -rf /usr/share/kibana/optimize # for some reason we have to remove it and let kibana optimize it on startup
fi

echo "DONE!"

33 changes: 27 additions & 6 deletions ror-demo-cluster/images/kbn/install-ror-kbn-using-file.sh
Original file line number Diff line number Diff line change
Expand Up @@ -28,11 +28,32 @@ elif greater_than_or_equal "$KBN_VERSION" "7.9.0" ; then
/usr/share/kibana/node/bin/node plugins/readonlyrestkbn/ror-tools.js patch --I_UNDERSTAND_AND_ACCEPT_KBN_PATCHING=yes
fi

if greater_than_or_equal "$KBN_VERSION" "7.9.0"; then
mv /usr/share/kibana/config/ror-newplatform-kibana.yml /usr/share/kibana/config/kibana.yml
else
mv /usr/share/kibana/config/ror-oldplatform-kibana.yml /usr/share/kibana/config/kibana.yml
rm -rf /usr/share/kibana/optimize # for some reason we have to remove it and let kibana optimize it on startup
fi
if greater_than_or_equal "$KBN_VERSION" "7.9.0"; then
case "${ROR_LICENSE_EDITION:-}" in
ENT)
mv /usr/share/kibana/config/enterprise-ror-newplatform-kibana.yml \
/usr/share/kibana/config/kibana.yml
;;
PRO)
mv /usr/share/kibana/config/pro-ror-newplatform-kibana.yml \
/usr/share/kibana/config/kibana.yml
;;
FREE)
mv /usr/share/kibana/config/free-ror-newplatform-kibana.yml \
/usr/share/kibana/config/kibana.yml
;;
"")
echo "ERROR: ROR_LICENSE_EDITION is not set" >&2
exit 1
;;
*)
echo "ERROR: Unsupported ROR_LICENSE_EDITION='${ROR_LICENSE_EDITION}'" >&2
exit 2
;;
esac
else
mv /usr/share/kibana/config/ror-oldplatform-kibana.yml /usr/share/kibana/config/kibana.yml
rm -rf /usr/share/kibana/optimize # for some reason we have to remove it and let kibana optimize it on startup
fi

echo "DONE!"
Binary file not shown.
30 changes: 28 additions & 2 deletions ror-demo-cluster/run.sh
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
#!/bin/bash -e

cd "$(dirname "$0")" || exit 1

if ! docker version &>/dev/null; then
echo "No Docker found. Docker is required to run this Sandbox. See https://docs.docker.com/engine/install/"
exit 1
Expand Down Expand Up @@ -28,9 +30,24 @@ echo -e "

./../utils/collect-info-about-ror-es-kbn.sh

# Call the extract helper using an explicit relative path (./../utils/...)
output="$(./../utils/extract_license_edition.sh "${ROR_ACTIVATION_KEY}" 2>&1)" rc=$?
if [ $rc -ne 0 ]; then
echo "ERROR: Failed to extract the ROR license edition (exit code: $rc)." >&2
echo "$output" >&2
exit $rc
elif [ -z "$output" ]; then
echo "ERROR: Could not determine the ROR license edition (the extract_license_edition helper returned no result)." >&2
exit 2
else
export ROR_LICENSE_EDITION="$output"
echo "Auto-detected ROR_LICENSE_EDITION=$ROR_LICENSE_EDITION"
fi

echo "Starting Elasticsearch and Kibana with installed ROR plugins ..."

docker compose up -d --build --wait --remove-orphans --force-recreate
docker compose --profile "${ROR_LICENSE_EDITION}" up -d --build --wait --remove-orphans --force-recreate

docker compose logs -f > ror-cluster.log 2>&1 &

echo -e "
Expand All @@ -41,4 +58,13 @@ echo -e "
***********************************************************************
"

echo -e "You can access ROR KBN here: https://localhost:15601 (users: 'user1:test', 'user2:test' or admin user: 'admin:admin')"
case "${ROR_LICENSE_EDITION:-}" in
ENT)
echo -e "You can access ROR KBN here: https://localhost:15601 (login via 'Keycloak' button; users: 'extUser1:extUser1', 'extUser2:extUser2').\nKeycloak admin console: http://kc.localhost:8080/admin (admin:admin)"
;;
PRO|FREE)
echo -e "You can access ROR KBN here: https://localhost:15601"
;;
*)
;;
esac
Loading