forked from diegoecab/oci-deal-accelerator
Diagram generation: ref-arch-driven procedure + spec validator + KB enrichment
The diagram path now follows a documented standard procedure (lookup the closest Oracle Architecture Center reference → confirm components → author absolute_layout → spec validator → render → visually verify) and ships persistent guardrails so layout regressions can't recur. Persistent procedure changes (apply to all users, all sessions): - tools/diagram_spec_validator.py — geometry checks (CONTAINER_TOO_THIN, CONTAINER_PADDING_VIOLATION, LABEL_OVERFLOW_PARENT) run BEFORE either renderer (drawio + PPTX). Catches the subnet-collapse / label-overflow bugs that the post-render drawio validator missed. - tools/oci_diagram_gen.py + tools/oci_pptx_diagram_gen.py — call the spec validator before emitting any output. Adds mysql / mysql_heatwave type aliases. - tools/archcenter_pattern_lookup.py — scores against cached page descriptions (not just the 1-line summary), supports --queries for multi-fragment composition, and applies synonym expansion via kb/architecture-center/synonyms.yaml so "LB HA cross AD" matches "load balancer high availability availability domain". - kb/architecture-center/synonyms.yaml — canonical synonym table (load balancer, autonomous database, data guard, …) used by the lookup scorer. KB enrichment: - tools/archcenter_description_fetcher.py + 121 cached _description.md under kb/diagram/assets/archcenter-refs/<slug>/. Removes the runtime dependency on docs.oracle.com when authoring specs and feeds the pattern-lookup scorer. - 110+ cached .drawio / .svg / .png references for offline reuse, plus the OCI Toolkit v24.2 import (kb/diagram/assets/oci-toolkit-drawio). Documentation: - docs/skill/output-formats.md — new "Standard diagram-generation procedure (MANDATORY)" + geometry rules + the new validator entry. - SKILL.md option 2 — references the mandatory procedure. - README.md — describes the spec validator, archcenter_pattern_lookup and description fetcher, and updates the KB-health table. Tooling that backs the procedure (cumulative across recent sessions): tools/archcenter_case_runner.py, archcenter_batch_driver.py, archcenter_zip_downloader.py, drawio_visual_validator.py, drawio_fidelity_eval.py, harvest_drawio_icon.py, import_oci_library.py, oci_pptx_diagram_gen.py, oci_pptx_render.py, refresh_pptx_icon_index.py. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
root
@@ -0,0 +1,278 @@
|
||||
# Secure TLS certificate deployment using OCI CA for OCI services and hybrid architectures
|
||||
|
||||
- Source: https://docs.oracle.com/en/solutions/secure-tls-oci-ca/index.html
|
||||
- Date: 2025-11
|
||||
- Type: reference-architecture
|
||||
- Services: vault, load-balancer
|
||||
- Tags: security, networking
|
||||
|
||||
## Summary (catalog)
|
||||
|
||||
OCI Certificate Authority for TLS certificate lifecycle management. Automated certificate rotation for Load Balancers, API Gateways, and custom applications. Hybrid CA trust chain with on-premises PKI.
|
||||
|
||||
## Architecture (fetched from source)
|
||||
|
||||
About Secure TLS Certificate Deployment
|
||||
|
||||
|
||||
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Previous
|
||||
Next
|
||||
JavaScript must be enabled to correctly display this content
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
About Secure TLS Certificate Deployment
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
This solution provides a secure, flexible, and compliant approach for organizations needing to use trusted TLS certificates in environments where Oracle Cloud Infrastructure Vault ’s key immutability would otherwise be a blocker. It effectively bridges the gap between OCI-native security models and real-world integration requirements across multiple Oracle and non-Oracle services.
|
||||
|
||||
|
||||
|
||||
When implementing secure TLS communication on web servers or application servers, it is essential to have access to the following components:
|
||||
|
||||
|
||||
|
||||
- The TLS certificate
|
||||
|
||||
- The root and intermediate (certificate chain)
|
||||
|
||||
- The corresponding private key
|
||||
|
||||
|
||||
Oracle Cloud
|
||||
Infrastructure (OCI) offers native certificate management services that enable the creation and lifecycle management of certificates intended for use within OCI-managed services. In this model, private keys are securely stored in OCI Vault and are not accessible to end users or external systems. While this enhances security, it limits flexibility in scenarios where full certificate and key control is required—such as deploying to external application servers or hybrid environments. It poses a challenge when attempting to use the certificate authority (CA) from OCI Certificates for systems that require direct access to both the certificate and the private key.
|
||||
|
||||
|
||||
|
||||
This becomes particularly problematic when integrating with services such as:
|
||||
|
||||
|
||||
|
||||
- Oracle
|
||||
Analytics Cloud
|
||||
|
||||
- Oracle Integration
|
||||
|
||||
- Web servers hosted on OCI Compute
|
||||
|
||||
- On-premises or edge applications
|
||||
|
||||
|
||||
These platforms typically require full control over the TLS certificate, including the ability to access the private key, in order to support secure communication and termination of SSL/TLS sessions.
|
||||
|
||||
|
||||
This solution playbook introduces a cross-product solution that addresses this limitation by enabling the use of OCI CA for hybrid environments:
|
||||
|
||||
|
||||
|
||||
- You generate a private key and certificate signing request (CSR) locally, outside OCI.
|
||||
|
||||
- The CSR is then signed by the OCI Certificates CA, maintaining trust within the OCI ecosystem.
|
||||
|
||||
|
||||
- The resulting signed certificate is combined with the locally generated private key and deployed to any service that requires it—whether in OCI, on-premises, or in another cloud.
|
||||
|
||||
|
||||
The following diagram illustrates this flow.
|
||||
|
||||
|
||||
Description of the illustration implement-oci-ca-ext.png
|
||||
|
||||
This method is best for:
|
||||
|
||||
|
||||
|
||||
- Non-production setups where cost-effective self-signed certificates are sufficient.
|
||||
|
||||
- Environments that require both certificate and private key control (such as custom servers or on-premises integrations).
|
||||
|
||||
- Scenarios where OCI-managed certificates (which hide private keys) are not compatible with external systems.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Before You Begin
|
||||
|
||||
|
||||
|
||||
|
||||
Before you begin, you need:
|
||||
|
||||
|
||||
|
||||
- An OCI Vault for securely storing private keys set up in OCI.
|
||||
|
||||
|
||||
- An OCI Certificates certificate authority (CA) set up and fully functional in OCI.
|
||||
|
||||
|
||||
- Access to the OpenSSL library on your local machine, so you can generate your private key.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
About Required Services and Roles
|
||||
|
||||
|
||||
|
||||
|
||||
This solution requires the following service and role:
|
||||
|
||||
|
||||
|
||||
- Oracle Cloud
|
||||
Infrastructure
|
||||
|
||||
|
||||
This is the role needed for the service.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Service Name: Role
|
||||
Required to...
|
||||
|
||||
|
||||
|
||||
|
||||
Oracle Cloud
|
||||
Infrastructure : Administrator
|
||||
|
||||
Manage obects in compartments, and read or manage certificates, buckets, vaults, and keys (see below).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
You can use a simple policy for certificate authority administrators, or, set up both an administrator and a dynamic group policy to segregate roles and responsibilities and restrict them by compartment. For example:
|
||||
|
||||
### Simple Policy for Tenant Administrators
|
||||
```
|
||||
Allow group CertificateAuthorityAdmins to manage certificate-authority-family in tenancy
|
||||
Allow group CertificateAuthorityAdmins to manage leaf-certificate-family in tenancy
|
||||
Allow group CertificateAuthorityAdmins to read vaults in tenancy
|
||||
Allow group CertificateAuthorityAdmins to read keys in tenancy
|
||||
Allow group CertificateAuthorityAdmins to use key-delegate in tenancy
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
### Policy for a Dynamic Group
|
||||
```
|
||||
Allow dynamic-group DynamicGroup to use keys in compartment DEF
|
||||
Allow dynamic-group DynamicGroup to manage objects in compartment XYZ
|
||||
```
|
||||
### Policy for Compartment Administrators
|
||||
```
|
||||
Allow group CertificateAuthorityAdmins to manage certificate-authority-family in compartment ABC
|
||||
Allow group CertificateAuthorityAdmins to read keys in compartment DEF
|
||||
Allow group CertificateAuthorityAdmins to use key-delegate in compartment DEF
|
||||
Allow group CertificateAuthorityAdmins to read buckets in compartment XYZ
|
||||
Allow group CertificateAuthorityAdmins to read vaults in compartment DEF
|
||||
```
|
||||
|
||||
See Oracle Products, Solutions, and Services to get what you need.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Title and Copyright Information
|
||||
|
||||
|
||||
|
||||
|
||||
Secure TLS certificate deployment using OCI CA for OCI services and hybrid architectures
|
||||
|
||||
|
||||
G44551-01
|
||||
|
||||
|
||||
November 2025
|
||||
|
||||
|
||||
Copyright © 2025,
|
||||
|
||||
Oracle and/or its affiliates.
|
||||
Reference in New Issue
Block a user