Understanding the OCI Policy Analysis Tool: An Overview

Managing identity and access in large Oracle Cloud Infrastructure (OCI) environments can be complex. As organizations scale, so does the number of compartments, groups, dynamic groups, and policy statements. Assessing who can do what—across thousands of permissions—can quickly become challenging, especially for administrators tasked with strengthening security and reducing risk.

To address these challenges, the OCI Policy Analysis Tool has emerged as an essential utility for OCI administrators and security practitioners. Designed to help visualize, interpret, and analyze OCI Identity and Access Management (IAM) policies, this tool provides clarity and insight into effective permissions across your cloud tenancy. 

What Is the OCI Policy Analysis Tool?

The OCI Policy Analysis Tool is an unofficial, open-source application targeted at users who need a deeper understanding of their OCI IAM posture. It goes beyond simple policy listing by loading all relevant identity and policy data and organizing it into a cohesive, searchable format. This empowers administrators to answer questions such as:

  • Which principals have excessive privileges in sensitive compartments?

  • Why is a particular service unable to perform an expected action?

  • How have policies changed over time? 

Built entirely with Python and leveraging the OCI Python SDK, the tool demonstrates how custom scripts and utilities can be authored to fill functional gaps and make cloud security operations more manageable. 

Key Capabilities and Features

Once loaded with the necessary data from your tenancy or a compliance extract, the OCI Policy Analysis Tool provides several analytical and visibility features:

  • Policy Browser: Explore and search policy statements across all compartments.

  • Policy Analysis: Filter and inspect parsed IAM policies, including subjects, actions, resources, and conditions.

  • Dynamic Group Insights: Review dynamic group matching rules to identify misconfigurations or unused groups.

  • User & Resource Principal Analysis: Determine effective permissions for users and resources based on group memberships.

  • Cross-Tenancy View: Analyze global policy statements such as Define, Admit, and Endorse.

  • Historical Comparison: Compare policy sets at different points in time to detect changes or anomalies.

These features are accessible through an intuitive, tabbed interface that helps administrators quickly locate information and understand complex relationships within IAM configurations. 

Additional Utility Functions

Beyond policy inspection, the tool offers usability enhancements that improve flexibility and extend analysis capabilities:

  • Caching: Load and save OCI policy and identity data locally for offline analysis.

  • Export / Import: Export analysis results to CSV or JSON for reporting or auditing.

  • Compliance Script Integration: Import data from standard compliance scripts to enrich policy insights.

  • AI-Assisted Insights: Receive natural-language explanations and risk annotations for policy statements.

  • Contextual Help: Each view provides embedded help to explain the relevance of data fields or features.

Advanced Analysis & Simulation

For deeper investigations, the tool also incorporates powerful extensions:

  • API Simulation: Test hypothetical API calls as specific principals to determine allowed or denied actions.

  • Policy Recommendations: Generate suggested remediation steps based on detected misconfigurations or over-privileged access patterns.

  • MCP Server Integration: Expose your OCI tenancy data to tools such as VS Code or generative AI systems for interactive analysis.

Getting Started

There are two main ways to run the OCI Policy Analysis Tool:

  1. Direct Python Execution:

    • Ensure Python 3.12 or newer is installed.

    • Create and activate a virtual environment.

    • Install the tool dependencies and run the UI program through Python.

    • Load your OCI configuration or authenticate using an instance principal. 

  2. Packaged Executable:

    • Download the binaries from the project’s GitHub releases.

    • Launch the platform-specific executable and follow on-screen prompts.

Once started, you can import tenancy data and begin exploring policies, dynamic groups, and user permissions from a consolidated view.

Conclusion

In complex OCI deployments, maintaining an accurate understanding of IAM policies and the effective permissions they grant is essential for security and compliance. The OCI Policy Analysis Tool provides administrators with a comprehensive way to visualize, analyze and assess policy configurations across an entire tenancy. Whether it’s identifying over-privileged users or tracking changes over time, this tool transforms raw policy data into actionable insights. 

Part 1 of this series focuses on the tool and how to get started; an upcoming Part 2 will explore the development journey and strategy behind the tool’s creation.

at No comments:

Resolving Public IP and Hostname Mappings Using dig and openssl

 In day-to-day infrastructure troubleshooting, especially in hybrid and cloud environments, verifying DNS mappings and certificate bindings is a routine yet critical task. Whether validating load balancer configurations, troubleshooting SSL issues, or confirming external exposure of services, having quick command-line methods can save significant time.

This article walks through two practical techniques:

  1. Identifying the public IP mapped to a DNS hostname

  2. Identifying the public hostname(s) associated with a public IP via SSL certificate inspection

1. Finding the Public IP Address for a Hostname

To determine the IP address associated with a public DNS record, the dig command is both simple and reliable.

Command

dig +short <public_url_hostname>

Example

dig +short example.mycompany.com

What It Does

  • Queries the DNS system for the A record.

  • +short ensures only the IP address is returned.

  • Works for publicly resolvable DNS records.

Sample Output

203.0.113.10

When to Use This

  • Validating DNS propagation

  • Confirming load balancer IP mapping

  • Verifying cutover during migrations

  • Troubleshooting connectivity issues

This is often the first step in confirming whether a hostname resolves to the expected public endpoint.

2. Finding Hostname(s) Mapped to a Public IP Using SSL Certificate

Reverse DNS lookups do not always return the expected hostname. However, if the server presents an SSL certificate, you can extract the Subject Alternative Names (SAN) from the certificate to identify the DNS names associated with that endpoint.

Command

openssl s_client -connect <public_url_host>:<port> -servername dummy </dev/null 2>/dev/null | \
openssl x509 -noout -text | grep DNS

Example

openssl s_client -connect 203.0.113.10:443 -servername dummy </dev/null 2>/dev/null | \
openssl x509 -noout -text | grep DNS

What This Command Does

  • openssl s_client -connect
    Establishes an SSL/TLS connection to the target IP and port.

  • -servername dummy
    Enables SNI (Server Name Indication). Some servers require SNI during TLS negotiation.

  • </dev/null 2>/dev/null
    Suppresses interactive input and hides connection noise.

  • openssl x509 -noout -text
    Extracts certificate details.

  • grep DNS
    Filters the output to display only DNS entries under the Subject Alternative Name section.

Sample Output

DNS:example.mycompany.com, DNS:www.example.mycompany.com

When to Use This

  • Identifying which hostname a public IP is serving

  • Validating SSL certificate bindings

  • Troubleshooting multi-domain load balancers

  • Confirming SAN entries after certificate renewal

Important Notes

  • This method works only if the service exposes an SSL certificate.

  • If multiple virtual hosts exist behind the same IP, SNI may affect which certificate is presented.

  • The certificate may contain multiple DNS entries.

at No comments:

Bring Your Own Certificate Authority (BYOCA) in OCI

Security and trust are foundational requirements for modern enterprise IT environments. Many organizations have invested heavily in mature Public Key Infrastructure (PKI) systems to support thousands of applications, meet regulatory mandates, and uphold long-standing trust chains. Rebuilding these systems for cloud deployments can be costly, complex, and disrupt established governance models.

To address this challenge, Oracle has introduced Bring Your Own Certificate Authority (BYOCA) for Oracle Cloud Infrastructure (OCI) Certificates. This feature enables enterprises to integrate their existing Certificate Authority (CA) infrastructure directly with OCI without relinquishing control of sensitive private keys. 

Why Bring Your Own CA Matters

Traditionally, OCI Certificates allowed customers to build PKI hierarchies in the cloud, create CAs, and manage certificate lifecycles with automation. However, many enterprises already operate trusted root CAs that are deeply embedded in internal and external systems. Migrating or recreating these root hierarchies in the cloud can pose operational, compliance, and risk management challenges—especially for organizations in highly regulated industries. 

With BYOCA, OCI now provides a mechanism to retain existing trust chains while leveraging cloud automation and lifecycle management. Enterprises can extend their on-premises PKI into the cloud in a secure and controlled manner, preserving compliance and ensuring uninterrupted trust continuity. 

How It Works

BYOCA allows you to import an existing root CA certificate into OCI Certificates simply by providing the PEM-encoded certificate. Importantly:

  • Private keys remain under your exclusive control and are never uploaded to OCI.

  • OCI registers the imported certificate as an externally managed root CA while maintaining trust relationships with existing PKI infrastructure.

  • You can generate subordinate Certificate Authorities (sub-CAs) in OCI by signing certificate signing requests (CSRs) externally and then uploading the signed subordinate certificates to OCI.

  • Once activated, these sub-CAs can issue certificates using secure, OCI-managed keys protected within OCI Vault and HSM infrastructure. 

This model bridges existing enterprise PKI investments with cloud automation and lifecycle management capabilities. It enhances interoperability across hybrid and multi-cloud deployments, enabling consistent certificate issuance and trust configurations across environments. 

Enterprise Benefits

The BYOCA approach delivers several advantages:

  • Leverage Existing Investments – Continue using established PKI policies, trust anchors, and governance frameworks without redesigning root hierarchies for the cloud. 

  • Improved Compliance and Governance – Maintain strict separation of duties, regulatory compliance, and audit requirements while integrating with OCI’s certificate lifecycle automation. 

  • Hybrid and Distributed Workloads – Easily support hybrid infrastructure, multi-cloud architectures, and distributed systems with consistent trust configurations. 

  • Operational Efficiency – Delegate the operational burden of subordinate CA lifecycle management to OCI while controlling root trust policies internally.

Getting Started

Importing and using BYOCA in OCI Certificates involves a few key steps:

  1. Import your external root CA certificate (PEM format) into OCI Certificates without exposing private keys. 

  2. Create subordinate CAs in OCI by generating CSRs and signing them with your root CA. 

  3. Upload the signed subordinate CA certificates to OCI and activate them for certificate issuance. 

Once configured, OCI Certificates can issue and manage certificates from these subordinate CAs, bringing the best of cloud automation together with trusted enterprise PKI. 

at No comments:

Understanding OCI Always Free Compute: Entitlements, Usage, and Reclamation Rules

 Oracle Cloud Infrastructure (OCI) provides a generous Always Free tier designed to help customers explore, build, and sustain lightweight workloads at no cost. While many OCI users are familiar with compute shapes, OCPUs, and metrics, the Always Free program introduces specific usage rules that are often misunderstood—particularly around idle resource reclamation.

This blog explains what Always Free compute is, how the free usage is calculated, and why Oracle may reclaim idle instances.

What Is OCI Always Free Compute?

Always Free is a long-term entitlement within Oracle Cloud Infrastructure that allows customers to run a limited set of resources indefinitely at no charge, provided they stay within defined usage thresholds.

For compute, the most commonly used Always Free option today is:

  • VM.Standard.A1.Flex (Ampere Arm-based)

This shape provides a monthly free allowance equivalent to:

  • 3,000 OCPU hours

  • 18,000 GB memory hours

In practical terms, this allows customers to run instances totaling up to 4 OCPUs and 24 GB of RAM continuously throughout the month without incurring cost.

How Usage Is Measured (OCPU Hours Explained)

OCI bills (or tracks free usage) based on consumption, not allocation.

An OCPU hour means:

One OCPU used for one hour

Examples:

  • 1 OCPU × 3,000 hours = 3,000 OCPU hours

  • 2 OCPUs × 1,500 hours = 3,000 OCPU hours

  • 4 OCPUs × 24 hours × ~30 days ≈ 2,880 OCPU hours

As long as both OCPU hours and memory hours remain within the free limits, no billing occurs.

Why Oracle Reclaims Always Free Instances

Because Always Free resources are shared and capacity-bound, Oracle enforces governance to prevent long-term reservation of unused infrastructure.

As part of this governance, idle Always Free compute instances may be reclaimed automatically.

What Does “Idle” Mean?

Oracle evaluates Always Free compute instances over a continuous 7-day period. An instance may be classified as idle if all of the following conditions are met during that period:

  • CPU utilization (95th percentile) is below 20%

  • Network utilization is below 20%

  • Memory utilization is below 20% (applies to A1 shapes only)

If these thresholds are consistently unmet, Oracle may stop and reclaim the instance.

Important Clarifications

  • Reclamation applies only to Always Free resources

  • Paid compute instances are not subject to this rule

  • Reclamation is automatic and may occur without prior notice

  • Boot volumes may remain, but the compute instance itself is removed

  • The policy is based on sustained inactivity, not brief idle periods

Practical Implications for OCI Users

For users running:

  • Bastion hosts

  • Lightweight application servers

  • Dev/test environments

  • Monitoring or automation nodes

…it is important to ensure some consistent activity exists. Instances that are powered on but doing “nothing” for extended periods are the most common candidates for reclamation.

Best Practices to Avoid Reclamation

  • Run periodic workloads or scheduled jobs

  • Ensure network traffic (even minimal) is present

  • Monitor CPU, memory, and network metrics

  • Treat Always Free as active-use infrastructure, not cold standby

Final Thoughts

OCI Always Free is a powerful offering when used as intended—for learning, development, and lightweight production use. Understanding how usage is calculated and how Oracle defines “idle” ensures you can design workloads that remain compliant, predictable, and cost-free.

Used correctly, Always Free compute can be a reliable foundation rather than a surprise outage.

at No comments:

Oracle AI Database 26ai Now Generally Available for On-Premises Linux x86-64 Platforms

Oracle has announced the general availability (GA) of Oracle AI Database 26ai Enterprise Edition for Linux x86-64 on-premises environments as part of the January 2026 quarterly Release Update (23.26.1). This milestone expands Oracle’s AI-native database platform beyond cloud and engineered systems into customer data centers, offering enterprises a broader choice for modern data and AI workloads. 

Bringing AI-Native Data Management to the Enterprise

Oracle AI Database 26ai represents the next generation of Oracle’s converged database architecture, embedding artificial intelligence deeply into the core of the database engine. With this release now available for on-premises Linux x86-64 systems, organizations that operate critical workloads within their own data centers can leverage AI capabilities without migrating to cloud-managed environments. 

This on-premises GA release ensures that enterprises with strict data sovereignty, security, compliance, or performance requirements can modernize their database platforms while taking full advantage of Oracle’s AI innovations. 

Key Capabilities in Oracle AI Database 26ai

The 26ai release includes a comprehensive set of AI-enabled features and enhancements designed to transform enterprise data management:

  • AI Vector Search – Support for similarity search across vectorized data, enabling intelligent retrieval of related documents, images, and other unstructured data. 

  • Globally Distributed Database with RAFT Replication – Built-in mechanisms for data replication across distributed environments.

  • In-Database SQL Firewall – Enhanced security controls for managing risky queries. 

  • Quantum-Resistant Encryption – Cryptographic protections designed to withstand future computational threats.

  • True Cache – Performance enhancements that optimize data access patterns.

  • JSON Relational Duality – Unified handling of JSON and relational data within the same platform. 

  • Apache Iceberg Lakehouse Support – Integration with modern open table formats for analytical workloads. 

This extensive feature set allows organizations to combine transactional, analytical, and AI-centric workloads within a single, unified database platform. 

What This Means for On-Premises Customers

Traditionally, advanced AI capabilities in Oracle databases were most accessible through cloud-hosted services or engineered systems such as Oracle Exadata. With the on-premises GA of Oracle AI Database 26ai for Linux x86-64, customers can now:

  • Preserve existing infrastructure investments while adopting state-of-the-art AI-native database technology. 

  • Simplify architectures by reducing dependency on external AI platforms or middleware. 

  • Accelerate application development and deployment with built-in AI functions. 

This release underscores Oracle’s commitment to offering flexibility across cloud and on-premises deployment models, ensuring enterprises can align technology choices with business requirements. 

Getting Started with Oracle AI Database 26ai On-Premises

Customers can download Oracle AI Database 26ai Enterprise Edition for Linux x86-64 from Oracle’s software distribution channels and begin planning upgrades or new deployments as part of their 2026 technology roadmap. 

For further details on the release, feature highlights, and tutorials, Oracle provides an array of resources, including product documentation, live labs, and introductory videos. 

Conclusion

The general availability of Oracle AI Database 26ai for on-premises Linux x86-64 systems marks a significant evolution in enterprise database technology. By seamlessly integrating AI capabilities into the database engine and extending them beyond cloud environments, Oracle empowers organizations to innovate faster, extract deeper insights, and maintain control over critical data–all within their own data centers.


at No comments:

Bringing Your Own Images into Oracle Cloud Infrastructure

Oracle Cloud Infrastructure allows customers to import external custom images; however, most of these images are originally built for environments that boot from local disks or use paravirtualized storage. While this works well for virtual machines, bare metal provisioning in OCI follows a different boot model and therefore requires additional preparation.

Why External Images Often Fail on Bare Metal

When an external image is imported into OCI and launched on a bare metal shape without modification, one or more of the following issues commonly occur:

  • The instance fails to complete the boot process

  • The operating system cannot locate the root filesystem

  • Network interfaces are not initialized during early boot

These behaviors are not platform defects. They indicate that the image lacks specific prerequisites required for bare metal booting in OCI.

Once these requirements are understood, the remediation is straightforward and enables the use of a single image across both virtual machine and bare metal instances.

Key Areas to Address for Image Compatibility

To ensure that one custom image works reliably across all OCI compute shapes, focus on the following three core areas.

1. Enable iSCSI Boot Support

Bare metal instances in OCI boot from network-attached storage using iSCSI. The operating system image must therefore support iSCSI during the earliest stages of the boot process.

At a minimum, the image should include:

  • Installation of the iSCSI initiator utilities (for example, iscsi-initiator-utils)

  • Required kernel parameters:

    • rd.iscsi.ibft=1

    • rd.iscsi.firmware=1

  • A rebuilt initramfs that incorporates iSCSI and networking support

With these elements in place, the operating system can:

  • Discover the boot volume presented by OCI

  • Initialize networking early enough to access the volume

  • Mount the root filesystem and continue the boot sequence

This configuration does not affect virtual machines, allowing the same disk layout to function on both VM and bare metal shapes.

2. Align Cloud-Init with OCI Requirements

Cloud-init is responsible for essential first-boot activities, including:

  • Applying SSH keys from instance metadata

  • Configuring network interfaces

  • Processing custom initialization scripts

External images frequently include outdated or incompatible cloud-init versions designed for other cloud platforms. For reliable operation in OCI, the image must:

  • Include cloud-init version 20.3 or later, which supports OCI as a data source

  • Remove or replace older cloud-init packages that may conflict

  • Configure Oracle Cloud Infrastructure as the authoritative metadata source

Once properly aligned, both virtual machine and bare metal instances initialize consistently and predictably.

3. Clean the Image Before Capture

Before converting the configured system into a reusable custom image, the operating system should be cleaned to remove residual state. This step prevents subtle and difficult-to-diagnose issues during future provisioning.

Recommended cleanup actions include:

  • Clearing cloud-init state and logs using cloud-init clean --logs

  • Removing old log files and temporary data

The objective is to ensure that every instance launched from the image behaves as a fresh deployment, regardless of the compute shape.

Summary

By enabling iSCSI boot support, ensuring cloud-init compatibility with OCI, and properly cleaning the image before capture, organizations can successfully reuse a single external custom image across both virtual machine and bare metal instances in Oracle Cloud Infrastructure. This approach reduces image sprawl, improves consistency, and simplifies operations across hybrid and cloud-native environments.

at No comments:

VCN Security List Allows Traffic to Restricted Ports – Alert Explanation and Remediation

 


An alert is generated in cloud guard when a Virtual Cloud Network (VCN) security list permits inbound traffic on ports classified as restricted. These ports are defined in the detector’s Restricted Protocol: Ports List within the input settings. Allowing such ports through ingress rules increases the attack surface and may expose workloads to unnecessary security risks.

This alert is raised to ensure that network access remains aligned with Oracle Cloud Infrastructure security best practices.

Impact

If restricted ports are allowed in VCN security list ingress rules, unauthorized or unintended access paths may be introduced. This can lead to compliance violations, increased vulnerability to network-based attacks, and deviation from established security baselines.

Recommended Resolution

Ensure that all VCN security lists do not allow any ports defined in the Restricted Protocol: Ports List through ingress (inbound) rules.

Specifically:

  • Review all security list ingress rules.

  • Remove or restrict any ports identified as restricted by the detector rule.

  • Validate that only explicitly required ports are permitted.

Steps to Update the Detector Rule

  1. Sign in to the OCI Console.

  2. Navigate to:
    Oracle Cloud Guard → Detector Recipes

  3. Open the relevant Detector Recipe.

  4. Select Detector Rules.

  5. Locate the rule “VCN Security List Allows Traffic to Restricted Port.”

  6. Edit the rule and remove port 111 from the Input Settings.

  7. Save and apply the changes.

Best Practices for Rule Customization

  • Controlled Configuration:
    Update the Restricted Protocol: Ports List only when there is a validated business or technical requirement.

  • Flexible Input Options:
    Restricted ports can be specified in two ways:

    • Manually entering individual port numbers or port ranges.

    • Referencing one or more predefined security lists by name.

  • Periodic Review:
    Regularly review detector rules and security list configurations to ensure continued alignment with organizational security standards.

Conclusion

Proactively managing restricted ports within VCN security lists is essential to maintaining a secure OCI networking posture. By refining detector rule input settings and enforcing strict ingress controls, organizations can significantly reduce exposure to unnecessary network risks while remaining compliant with OCI security best practices.

at No comments:
Subscribe to: Comments (Atom)