oci-api 0.8.0

OCI (Oracle Cloud Infrastructure) API client for Rust
Documentation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
# oci-api

A Rust client library for Oracle Cloud Infrastructure (OCI) APIs.

Currently supports:
- **Email Delivery Service** - Send emails via OCI Email Delivery
- **Object Storage Service** - Manage buckets and objects
- **Vault Secrets Service** - Read current, staged, and versioned secret bundles
- **Keys Service** - Read keys and trigger rotation

## Features

- 🔐 OCI HTTP request signing (compliant with OCI specifications)
- 🔄 Dual auth modes: API key and Instance Principal
- 📧 Email Delivery API support
- 🗝️ Vault Secrets and Keys support
- 🔄 Async/await support (Tokio)
- 🛡️ Type-safe API with comprehensive error handling
- ⚙️ Flexible configuration (environment variables, config files, or programmatic)

## Installation

Add this to your `Cargo.toml`:

```toml
[dependencies]
oci-api = "0.8.0"
tokio = { version = "1", features = ["full"] }
```

**Import commonly used types:**

```rust
use oci_api::Oci;
use oci_api::email::{EmailDelivery, Email, EmailAddress, Recipients};
use oci_api::keys::KeysClient;
use oci_api::object_storage::ObjectStorage;
use oci_api::vault::VaultSecretsClient;
```


## Configuration

`oci-api` supports two authentication modes via the `OCI_AUTH_MODE` environment variable:

| Mode | Value | Typical runtime |
|------|-------|-----------------|
| API key | `api_key` | local development, CI, explicit credential injection |
| Instance Principal | `instance_principal` | OCI-hosted runtime with instance identity |

When `OCI_AUTH_MODE` is unset, `oci-api` uses this precedence:

1. Short OCI metadata probe (`/opc/v2/instance/regionInfo`)
2. If OCI metadata is reachable, default to `instance_principal`
3. Otherwise, fall back to `api_key`

This keeps OCI-hosted runtimes on the workload-identity path by default while preserving API key usage for local and non-OCI environments.

### Option A: Instance Principal

Use Instance Principal when the workload runs on OCI and should use the instance's workload identity. You can set it explicitly, or leave `OCI_AUTH_MODE` unset on OCI and let `oci-api` autodetect it.

```bash
OCI_AUTH_MODE=instance_principal

# optional: override metadata endpoint for local mock tests
OCI_METADATA_BASE_URL=http://169.254.169.254/opc/v2
```

```rust
use oci_api::Oci;

let oci = Oci::from_env()?;
assert_eq!(oci.auth_mode(), oci_api::client::AuthMode::InstancePrincipal);
```

Instance Principal notes:

- No auth credential environment variables are required on OCI-hosted runtimes.
- `OCI_REGION` and `OCI_TENANCY_ID` are auto-discovered when OCI metadata and the instance leaf certificate are available.
- If `OCI_AUTH_MODE` is unset, OCI metadata reachability makes `instance_principal` the default path.
- Auth tokens, session keys, and service endpoints are resolved lazily and refreshed automatically.
- Resource-target variables such as secret OCIDs, bucket names, namespaces, or KMS endpoints remain separate from authentication configuration.
- The runtime must belong to a dynamic group with policies for each target OCI service.
- If the runtime is outside OCI, use `api_key` mode instead.

#### Example Instance Principal policies

The exact policy set depends on the services you call. For the currently implemented services, read-oriented access typically looks like this:

```text
Allow dynamic-group <dynamic-group-name> to read keys in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read secret-family in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read buckets in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read objects in compartment <compartment-name>
Allow dynamic-group <dynamic-group-name> to read email-family in compartment <compartment-name>
```

Notes:

- Keys and secrets are compartment-scoped.
- Object Storage object reads require `read objects` in addition to `read buckets`.
- Email Delivery control-plane reads can be compartment-scoped.

### Option B: API Key

Use API key mode for local development, CI, or any runtime outside OCI.

#### Option B-1: Environment Variables (Recommended)

OCI credentials used for generating(signing) `Authorization` headers and requests can be loaded from environment variables or from `OCI_CONFIG`.

**Using `OCI_CONFIG` (supports both file path and INI content directly)**

`OCI_CONFIG` can provide the following information:
- `user``user_id`
- `tenancy``tenancy_id`
- `region`
- `fingerprint`
- `key_file`: path to private key file


```bash
# use dotenvy or similar to load environment variables from `.env` in development

# point to a config file path
OCI_CONFIG=/path/to/.oci/config

# or provide content(INI) directly
OCI_CONFIG="[DEFAULT]
user=ocid1.user.oc1..aaaaaa...
tenancy=ocid1.tenancy.oc1..aaaaaa...
region=ap-chuncheon-1
fingerprint=aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:00
key_file=~/.oci/private-key.pem"
```

**Using `OCI_PRIVATE_KEY` (supports both file path and PEM content directly):**
```bash
# it overrides the private key specified in OCI_CONFIG if both are set

# Provide private key file path
OCI_PRIVATE_KEY=/path/to/private-key.pem
# or provide PEM content directly:
OCI_PRIVATE_KEY="-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgk...
-----END PRIVATE KEY-----"
```

**Individual environment variables override `OCI_CONFIG` example:**

```bash

# if you use individual vars, you don't need to set OCI_CONFIG
# but you can still use it as a base
OCI_CONFIG=/path/to/.oci/config

# Override specific values (higher priority than OCI_CONFIG)
OCI_USER_ID=ocid1.user.oc1..different...      # Overrides 'user' from config
OCI_TENANCY_ID=ocid1.tenancy.oc1..different...  # Overrides 'tenancy' from config
OCI_REGION=ap-seoul-1                          # Overrides 'region' from config
OCI_FINGERPRINT=11:22:33:44:55:66:77:88:99:00:aa:bb:cc:dd:ee:ff  # Overrides 'fingerprint'
OCI_PRIVATE_KEY=/different/path/to/key.pem    # Overrides 'key_file' from config
OCI_COMPARTMENT_ID=ocid1.compartment.oc1..aaaaaa...  # Optional, defaults to tenancy_id, but needed for APIs if you use specific compartment
```

**Load configuration:**

```rust
use oci_api::Oci;

let oci = Oci::from_env()?;
```

**Priority Summary:**

| Field | Priority 1  | Priority 2 | 
|-------|---------------------|------------|
| User ID | `OCI_USER_ID` | `user` from `OCI_CONFIG` | 
| Tenancy ID | `OCI_TENANCY_ID` | `tenancy` from `OCI_CONFIG` | 
| Region | `OCI_REGION` | `region` from `OCI_CONFIG` | 
| Fingerprint | `OCI_FINGERPRINT` | `fingerprint` from `OCI_CONFIG` | 
| Private Key | `OCI_PRIVATE_KEY` (file path or content) | `key_file` from `OCI_CONFIG` | 
| Compartment ID | `OCI_COMPARTMENT_ID` | Defaults to `tenancy_id` | 

\* `OCI_USER_ID`, `OCI_TENANCY_ID`, `OCI_REGION`, `OCI_FINGERPRINT`, and `OCI_PRIVATE_KEY` are required if `OCI_CONFIG` is not set.
\* `OCI_PRIVATE_KEY` is recommended even if `OCI_CONFIG` is used, if you do not want to change the config file content between environments.

#### Option B-2: Programmatic Configuration

```rust
use oci_api::Oci;

// build from scratch using individual fields
let oci = Oci::builder()
    .user_id("ocid1.user.oc1..aaaaaa...")
    .tenancy_id("ocid1.tenancy.oc1..aaaaaa...")
    .region("ap-chuncheon-1")
    .fingerprint("aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:00")
    .private_key("/path/to/private-key.pem")?
    .compartment_id("ocid1.compartment.oc1..aaaaaa...")
    .build()?;

// or load from config file and override specific fields
let oci = Oci::builder()
    .config("/path/to/.oci/config")?  // Load from file
    .private_key("/production/path/to/key.pem")?  // Override key_file from config
    .compartment_id("ocid1.compartment.oc1..aaaaaa...")  // Set compartment
    .build()?;

```







## Email Delivery API

```rust
use oci_api::Oci;
use oci_api::email::{EmailDelivery, Email, EmailAddress, Recipients};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // create an email delivery instance
    let oci = Oci::from_env()?;
    let email_delivery = EmailDelivery::new(oci).await?;
    // or chaining from oci
    let email_delivery = Oci::from_env()?.email_delivery().await?;
    
    // make an email
    let email = Email::builder()
        .sender(EmailAddress::new("approved-sender@example.com"))  // Must be an approved sender
        .recipients(Recipients::to(vec![EmailAddress::new("recipient@example.com")]))
        .subject("Hello from OCI!")
        .body_html("<h1>This is a test email</h1><p>Sent via <strong>OCI Email Delivery API</strong>.</p>")
        .body_text("This is a test email sent via OCI Email Delivery API.")
        .build()?;
    
    // send email
    let response = email_delivery.send(email).await?;
    println!("Email sent! Message ID: {}", response.message_id);
    
    Ok(())
}
```

### Body Text & HTML

you can send body as text or HTML or both, but at least one is required. if both are provided(recommended), email clients will choose HTML if available, otherwise plain text.

```rust
use oci_api::Oci;
use oci_api::email::{EmailDelivery, Email, EmailAddress, Recipients};

let email = Email::builder()
    .sender(EmailAddress::new("approved-sender@example.com"))
    .recipients(Recipients::to(vec![EmailAddress::new("user@example.com")]))
    .subject("Simple Email")
    .body_html("<h1>Hello</h1><p>This is <strong>HTML</strong> content.</p>")
    .body_text("Plain text content")
    .build()?;

let response = email_delivery.send(email).await?;
```


### Email Address

EmailAddress is used for specifying sender, recipients, reply-to, etc. it can be created with just an email(`new`) or with a display name(`with_name`).

```rust
let just_email = EmailAddress::new("user@example.com");
let with_name = EmailAddress::with_name("user@example.com", "User Name");
```

#### Recipients

Recipients needs at least one `to` or `cc` or `bcc` recipient.
You can use builder pattern or multiple Recipients constructors(`to`(=`new`), `cc`, `bcc`) to create recipients,
and you can also add more recipients using `add_to`, `add_cc`, `add_bcc` methods.
each `to`, `cc`, `bcc` recipients will be unique by `EmailAddress.email` when constructed or added.

```rust
// Option 1: Using builder pattern (flexible for multiple fields)
let email = Email::builder()
    .sender(EmailAddress::new("approved-sender@example.com"))
    .subject("Group Email")
    .body_text("This email has CC and BCC recipients")
    .recipients(
        Recipients::builder() // it must be built with at least one of `to`, `cc`, `bcc`
            .to(vec![
                EmailAddress::new("to1@example.com"),
                EmailAddress::with_name("to1@example.com", "to1"), // duplicate, will be ignored
                EmailAddress::with_name("to2@example.com", "User Two"),
            ])
            .cc(vec![EmailAddress::new("cc@example.com")])
            .bcc(vec![EmailAddress::new("bcc@example.com")])
            .build()
    )
    .build()?;

// Option 2: Using specific constructor and add with `add_*` methods (chainable)
let email = Email::builder()
    .sender(EmailAddress::new("approved-sender@example.com"))
    .subject("Group Email")
    .body_text("This email has CC and BCC recipients")
    .recipients(
        Recipients::to(vec![EmailAddress::new("to@example.com")]) // create with `to` recipients
            .add_to(vec![
                EmailAddress::with_name("to@example.com", "To User"), // duplicate, will be ignored
                EmailAddress::new("to2@example.com"), // will be added to `to` recipients
            ])
            .add_cc(vec![EmailAddress::new("cc@example.com")])
            .add_bcc(vec![EmailAddress::new("bcc@example.com")])
    )
    .build()?;

let response = email_client.send(email).await?;
```

You can also use `headers`(headerFields), `reply_to`(replyTo), and `message_id`(messageId) fields in `Email` struct. you can reference [here](https://docs.oracle.com/en-us/iaas/api/#/en/emaildeliverysubmission/20220926/datatypes/SubmitEmailDetails)

### Testing with `EmailSender` trait

`EmailDelivery` implements the `EmailSender` trait, which allows you to inject mock implementations for testing:

```rust
use oci_api::email::{EmailSender, EmailDelivery, Email, SubmitEmailResponse};
use oci_api::{async_trait, Result};
use std::sync::{Arc, Mutex};

// Create a mock implementation for testing
struct MockEmailSender {
    sent: Arc<Mutex<Vec<String>>>,
}

#[async_trait]
impl EmailSender for MockEmailSender {
    async fn send(&self, email: Email) -> Result<SubmitEmailResponse> {
        self.sent.lock().unwrap().push(email.subject.clone());
        Ok(SubmitEmailResponse {
            message_id: "mock-id".to_owned(),
            envelope_id: "mock-env".to_owned(),
            suppressed_recipients: None,
        })
    }
}

// Use trait object for dependency injection
async fn send_welcome(sender: &dyn EmailSender, email: Email) -> Result<SubmitEmailResponse> {
    sender.send(email).await
}
```

This pattern lets you:
- **Production**: Use `Arc<dyn EmailSender>` with `EmailDelivery` (real OCI API)
- **Test**: Use `Arc<dyn EmailSender>` with a mock (no network calls, verify sent emails)

For OCI Email Delivery documentation, see:
- [OCI Email Delivery Overview]https://docs.oracle.com/en-us/iaas/Content/Email/home.htm
- [OCI Email Delivery API Reference]https://docs.oracle.com/en-us/iaas/api/#/en/emaildelivery/20170907/
- [OCI Email Delivery Submission API Reference]https://docs.oracle.com/en-us/iaas/api/#/en/emaildeliverysubmission/20220926/

<br>

## Object Storage API

```rust
use oci_api::Oci;
use oci_api::object_storage::ObjectStorage;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Create an object storage instance
    let oci_client = Oci::from_env()?;
    let storage = ObjectStorage::new(&oci_client, "your_namespace");
    // or chaining from Oci directly
    let storage = Oci::from_env()?.object_storage("your_namespace");

    // Get Bucket
    let bucket = storage.get_bucket("your-bucket-name").await?;

    // Put Object
    let object_name = "test-object.txt";
    let value = "Hello, OCI Object Storage!";
    let object = bucket.put_object(object_name, value).await?;

    // Put Object with Checksum (Optional)
    use oci_api::services::object_storage::models::ChecksumAlgorithm;
    let object = bucket.put_object_with_checksum(
        object_name, 
        value, 
        ChecksumAlgorithm::SHA256
    ).await?;

    // Get Object
    let object = bucket.get_object(object_name).await?;

    // Get or Create Object(if not exists)
    let object = bucket.get_or_create_object(object_name, value).await?;
}
```

you can also work with retention rules for a bucket

```rust
use oci_api::services::object_storage::models::{RetentionRuleDetails, RetentionDuration, RetentionTimeUnit};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let bucket = Oci::from_env()?
        .object_storage("your_namespace")
        .get_bucket("your-bucket-name")
        .await?;

    // Create a Retention Rule
    let details = RetentionRuleDetails {
        display_name: Some("My Rule".to_string()),
        duration: Some(RetentionDuration {
            time_amount: 30,
            time_unit: RetentionTimeUnit::Days,
        }),
        time_rule_locked: None,
    };
    let rule = bucket.create_retention_rule(details).await?;

    // Get Retention Rules Vector
    let rules = bucket.get_retention_rules().await?;

    // Get Retention Rule by ID
    let rule = bucket.get_retention_rule(&rule.id).await?;

    // Update Retention Rule
    let update_details = RetentionRuleDetails {
        display_name: Some("My Rule Updated".to_string()),
        ..Default::default()
    };
    let updated_rule = bucket.update_retention_rule(&rule, update_details).await?;

    // Delete Retention Rule
    bucket.delete_retention_rule(&rule).await?;
    
    Ok(())
}
```

### Object Integrity

It automatically maps available checksum headers into `md5`(`Content-MD5`)
and `checksum`(`opc-content-sha256`|`opc-content-sha384`|`opc-content-crc32c`) fields.

 You can verify the integrity of the downloaded object using the `verify_checksums()` method.

```rust
use oci_api::services::object_storage::models::ChecksumAlgorithm;

let object = bucket.get_object("my-object").await?;

// Verify integrity against all available checksums
// Returns Ok(()) if all present checksums match, or an Error if any mismatch
object.verify_checksums()?;

// Access specific checksums
println!("MD5: {}", object.md5);

if let Some(checksum) = &object.checksum {
    match checksum.algorithm {
        ChecksumAlgorithm::SHA256 => println!("SHA256: {}", checksum.value),
        ChecksumAlgorithm::SHA384 => println!("SHA384: {}", checksum.value),
        ChecksumAlgorithm::CRC32C => println!("CRC32C: {}", checksum.value),
    }
}
```

For OCI Object Storage documentation, see:
- [OCI Object Storage Overview]https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/objectstorageoverview.htm
- [OCI Object Storage API Reference]https://docs.oracle.com/en-us/iaas/api/#/en/objectstorage/20160918/

<br>

## Vault Secrets API

```rust
use oci_api::Oci;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let oci = Oci::from_env()?;
    let vault = oci.vault();

    let current = vault.get_secret_bundle("ocid1.vaultsecret.oc1..example").await?;
    let current_value = current.secret_bundle_content.decoded_string()?;

    let pending = vault
        .get_secret_bundle_by_stage("ocid1.vaultsecret.oc1..example", "PENDING")
        .await?;

    let previous = vault
        .get_secret_bundle_by_version("ocid1.vaultsecret.oc1..example", 3)
        .await?;

    println!("current secret: {current_value}");
    println!("pending stages: {:?}", pending.stages);
    println!("previous version: {:?}", previous.version_number);
    Ok(())
}
```

Phase 1 scope intentionally focuses on:

- current secret bundle lookup
- staged secret bundle lookup
- versioned secret bundle lookup

## Keys API

```rust
use oci_api::Oci;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let oci = Oci::from_env()?;

    // Use the KMS management endpoint for the target vault.
    let keys = oci.keys("management.kms.ap-seoul-1.oci.oraclecloud.com");

    let key = keys.get_key("ocid1.key.oc1.ap-seoul-1.example").await?;
    let rotated = keys.rotate_key("ocid1.key.oc1.ap-seoul-1.example").await?;

    println!("key: {}", key.id);
    println!("rotated version: {:?}", rotated.current_key_version);
    Ok(())
}
```

Phase 1 scope intentionally focuses on:

- key lookup
- rotate action

<br>

## Error Handling

The library provides comprehensive error types:

```rust
use oci_api::{Error, Result};

match email_client.send(email).await {
    Ok(response) => println!("Sent: {}", response.message_id),
    Err(Error::ApiError(status, body)) => {
        eprintln!("API error {}: {}", status, body);
    }
    Err(Error::AuthError(msg)) => {
        eprintln!("Authentication error: {}", msg);
    }
    Err(e) => eprintln!("Other error: {}", e),
}
```

Error types:
- `ConfigError` - Configuration loading/validation errors
- `EnvError` - Environment variable errors
- `KeyError` - Private key loading errors
- `AuthError` - Authentication/signing errors
- `ApiError` - OCI API errors (with HTTP status and response body)
- `NetworkError` - Network/HTTP client errors
- `IniError` - Config file parsing errors
- `Other` - Other errors


## License

MIT

## Contributing

Contributions are welcome! Please feel free to submit a Pull Request.


## Support

For issues and feature requests, please use [GitHub Issues](https://github.com/GoCoder7/rust-oci-api/issues).
You can request any OCI APIs, and I will try to implement them as soon as possible.