Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Tutorial IAM: Delegasikan akses di seluruh AWS akun menggunakan peran IAM
**penting**
[Praktik terbaik](best-practices.md) IAM merekomendasikan agar Anda mengharuskan pengguna manusia untuk menggunakan federasi dengan penyedia identitas untuk mengakses AWS menggunakan kredensil sementara alih-alih menggunakan pengguna IAM dengan kredensil jangka panjang. Kami menyarankan Anda hanya menggunakan pengguna IAM untuk [kasus penggunaan tertentu](gs-identities-iam-users.md) yang tidak didukung oleh pengguna federasi.
Tutorial ini mengajarkan Anda bagaimana menggunakan peran untuk mendelegasikan akses ke sumber daya yang berbeda Akun AWS disebut **Destination** and **Originating**. Anda berbagi sumber daya di satu akun dengan pengguna di akun yang berbeda. Dengan mengatur akses lintas akun dengan cara ini, Anda tidak perlu membuat pengguna IAM individual di setiap akun. Selain itu, pengguna tidak perlu keluar dari satu akun dan masuk ke akun lain untuk mengakses sumber daya yang berbeda Akun AWS. Setelah mengonfigurasi peran, Anda melihat cara menggunakan peran dari Konsol Manajemen AWS, the AWS CLI, dan API.
Dalam tutorial ini, akun **Tujuan** mengelola data aplikasi yang diakses oleh berbagai aplikasi dan tim. Di setiap akun, Anda menyimpan informasi aplikasi di ember Amazon S3. **Anda mengelola pengguna IAM di akun **Originating**, di mana Anda memiliki dua peran pengguna IAM: **Pengembang** dan Analis.** Pengembang dan Analis menggunakan akun **Originating** untuk menghasilkan data yang dibagikan oleh beberapa layanan mikro. Kedua peran memiliki izin untuk bekerja di akun Originating dan mengakses sumber daya di sana. Dari waktu ke waktu, pengembang harus memperbarui data bersama di akun **Tujuan**. Pengembang menyimpan data ini dalam ember Amazon S3 yang disebut. `amzn-s3-demo-bucket-shared-container`
Di akhir tutorial ini, Anda memiliki hal berikut:
+ Pengguna di akun **Originating** (akun tepercaya) diizinkan untuk mengambil peran tertentu dalam akun **Tujuan**.
+ Peran di akun **Tujuan** (akun kepercayaan) diizinkan untuk mengakses bucket Amazon S3 tertentu.
+ `amzn-s3-demo-bucket-shared-container`Bucket di akun **Tujuan**.
Pengembang dapat menggunakan peran dalam Konsol Manajemen AWS untuk mengakses `amzn-s3-demo-bucket-shared-container` bucket di akun **Destination**. Mereka juga dapat mengakses bucket dengan menggunakan panggilan API yang diautentikasi oleh kredensi sementara yang disediakan oleh peran. Upaya serupa oleh seorang Analis untuk menggunakan peran gagal.
Alur kerja ini memiliki tiga langkah dasar:
**[Membuat peran di Akun Tujuan](#tutorial_cross-account-with-roles-1)**
Pertama, Anda menggunakan Konsol Manajemen AWS untuk membangun kepercayaan antara akun **Tujuan** (nomor ID 999999999999) dan akun **Originating** (nomor ID 1111111111). Anda mulai dengan membuat peran IAM bernama *UpdateData*. Saat membuat peran, Anda menentukan akun **Originating** sebagai entitas tepercaya dan menentukan kebijakan izin yang memungkinkan pengguna tepercaya memperbarui bucket. `amzn-s3-demo-bucket-shared-container`
**[Berikan akses ke peran tersebut](#tutorial_cross-account-with-roles-2)**
Di bagian ini, Anda mengubah kebijakan peran untuk menolak akses Analis ke `UpdateData` peran tersebut. Karena Analis memiliki PowerUser akses dalam skenario ini, dan Anda harus secara eksplisit *menolak* kemampuan untuk menggunakan peran tersebut.
**[Akses uji dengan mengalihkan peran](#tutorial_cross-account-with-roles-3)**
Terakhir, sebagai Pengembang, Anda menggunakan `UpdateData` peran untuk memperbarui `amzn-s3-demo-bucket-shared-container` bucket di akun **Tujuan**. Anda melihat cara mengakses peran melalui AWS konsol, the AWS CLI, dan API.
## Pertimbangan-pertimbangan
Sebelum Anda menggunakan peran IAM untuk mendelegasikan akses sumber daya Akun AWS, penting untuk mempertimbangkan hal berikut:
+ Anda tidak dapat beralih ke peran ketika Anda masuk sebagai Pengguna root akun AWS.
+ Peran IAM dan kebijakan berbasis sumber daya mendelegasikan akses ke seluruh akun hanya dengan satu partisi. Misalnya, anggap saja Anda memiliki akun di AS Barat (California Utara) di partisi `aws` standar. Anda juga memiliki rekening di Tiongkok (Beijing) di partisi `aws-cn` tersebut. Anda tidak dapat menggunakan kebijakan berbasis sumber daya Amazon S3 di akun Anda di Tiongkok (Beijing) untuk mengizinkan akses bagi pengguna dalam akun standar `aws` Anda.
+ Anda dapat menggunakan AWS IAM Identity Center untuk memfasilitasi single sign-on (SSO) untuk eksternal Akun AWS (akun di luar Anda) menggunakan Security Assertion Markup Language (SALL AWS Organizations). Untuk detailnya, lihat [Mengintegrasikan eksternal Akun AWS ke dalam AWS IAM Identity Center untuk manajemen akses pusat dengan penagihan independen menggunakan SAFL 2.0](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en)
+ Anda dapat mengaitkan peran ke AWS sumber daya seperti instans atau fungsi Amazon EC2. AWS Lambda Lihat perinciannya di [Membuat peran untuk mendelegasikan izin ke layanan AWS](id_roles_create_for-service.md).
+ Jika Anda ingin aplikasi mengambil peran di aplikasi lain Akun AWS, Anda dapat menggunakan AWS SDK untuk asumsi peran lintas akun. Untuk informasi selengkapnya, lihat [Otentikasi dan akses](https://docs.aws.amazon.com//sdkref/latest/guide/access.html) di *Panduan Referensi Alat AWS SDKs dan Alat*.
+ Beralih peran menggunakan Konsol Manajemen AWS satu-satunya berfungsi dengan akun yang tidak memerlukan file`ExternalId`. Misalnya, Anda memberikan akses untuk akun Anda ke pihak ketiga dan memerlukan `ExternalId` dalam elemen `Condition` dalam kebijakan izin Anda. Dalam hal ini, pihak ketiga dapat mengakses akun Anda hanya dengan menggunakan AWS API atau alat baris perintah. Pihak ketiga tidak dapat menggunakan konsol karena harus memberikan nilai untuk`ExternalId`. Untuk informasi selengkapnya tentang skenario ini[Akses ke Akun AWS yang dimiliki oleh pihak ketiga](id_roles_common-scenarios_third-party.md), lihat, dan [Cara mengaktifkan akses lintas akun ke Konsol Manajemen AWS](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) dalam Blog AWS Keamanan.
## Prasyarat
Tutorial ini mengasumsikan bahwa Anda telah melakukan hal berikut:
+ **Dua** terpisah Akun AWS yang dapat Anda gunakan, satu untuk mewakili akun **Originating**, dan satu untuk mewakili akun **Tujuan**.
+ Pengguna dan peran dalam akun **Originating** dibuat dan dikonfigurasi sebagai berikut:
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ Anda tidak perlu membuat pengguna apa pun di akun **Tujuan**.
+ Bucket Amazon S3 yang dibuat di akun **Tujuan**. Anda dapat menyebutnya `amzn-s3-demo-bucket-shared-container` dalam tutorial ini, tetapi karena nama bucket S3 harus unik secara global, Anda harus menggunakan bucket dengan nama yang berbeda.
## Membuat peran di Akun Tujuan
Anda dapat mengizinkan pengguna dari satu Akun AWS untuk mengakses sumber daya di sumber lain Akun AWS. Dalam tutorial ini, kita akan melakukan ini dengan membuat peran yang mendefinisikan siapa yang dapat mengaksesnya dan izin apa yang diberikannya kepada pengguna yang beralih ke sana.
Pada langkah tutorial ini, Anda membuat peran di akun **Tujuan** dan menentukan akun **Originating** sebagai entitas tepercaya. Anda juga membatasi izin peran untuk hanya membaca dan menulis akses ke `amzn-s3-demo-bucket-shared-container` bucket. Siapa pun yang diberi izin untuk menggunakan peran dapat membaca dan menulis ke `shared-container` ember.
Sebelum Anda dapat membuat peran, Anda memerlukan *ID akun* dari **Originating.** Akun AWS Masing-masing Akun AWS memiliki ID ID akun unik yang ditetapkan untuk itu.
**Untuk mendapatkan Originating ID Akun AWS**
1. Masuk ke Konsol Manajemen AWS sebagai administrator akun **Originating**, dan buka konsol IAM di. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Di konsol IAM, pilih nama pengguna Anda di bilah navigasi di kanan atas. Biasanya terlihat seperti ini: ***username*@ *account\$1ID\$1number\$1or\$1alias***.
**Untuk skenario ini, Anda dapat menggunakan ID akun 111111111111 untuk akun Originating.** Namun, Anda harus menggunakan ID akun yang valid jika Anda menggunakan skenario ini di lingkungan pengujian Anda.
**Untuk membuat peran di akun Tujuan yang dapat digunakan oleh akun Originating**
1. Masuk ke Konsol Manajemen AWS sebagai administrator akun **Tujuan**, dan buka konsol IAM.
1. Sebelum membuat peran, siapkan kebijakan terkelola yang menentukan izin untuk persyaratan peran. Anda kemudian perlu melampirkan kebijakan ini ke peran tersebut pada langkah berikutnya.
Anda ingin mengatur akses baca dan tulis ke bucket `amzn-s3-demo-bucket-shared-container`. Meskipun AWS menyediakan beberapa kebijakan terkelola Amazon S3, tidak ada satu pun yang menyediakan akses baca dan tulis ke satu bucket Amazon S3. Anda dapat membuat kebijakan Anda sendiri.
Pada panel navigasi, silakan pilih **Kebijakan** dan kemudian pilih **Buat kebijakan**.
1. Pilih tab **JSON** dan salin teks dari dokumen kebijakan JSON berikut. Rekatkan teks ini ke dalam kotak teks **JSON**, ganti sumber daya ARN `arn:aws:s3:::shared-container` () dengan yang asli untuk bucket Amazon S3 Anda.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
```
------
`ListAllMyBuckets`Tindakan tersebut memberikan izin untuk mencantumkan semua bucket yang dimiliki oleh pengirim permintaan yang diautentikasi. Izin `ListBucket` memungkinkan pengguna melihat objek dalam bucket `amzn-s3-demo-bucket-shared-container`. Izin `GetObject`, `PutObject`, `DeleteObject` memungkinkan pengguna melihat, memperbarui, dan menghapus konten di bucket `amzn-s3-demo-bucket-shared-container`.
**catatan**
Anda dapat beralih antara opsi editor **Visual** dan **JSON** kapan saja. Namun, jika Anda melakukan perubahan atau memilih **Berikutnya** di editor **Visual**, IAM dapat merestrukturisasi kebijakan Anda untuk mengoptimalkannya bagi editor visual. Untuk informasi selengkapnya, lihat [Restrukturisasi kebijakan](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Pada halaman **Tinjau dan buat**, ketik **read-write-app-bucket** nama kebijakan. Tinjau izin yang diberikan oleh kebijakan Anda, lalu pilih **Buat kebijakan** untuk menyimpan pekerjaan Anda.
Kebijakan baru muncul di daftar kebijakan terkelola.
1. Pada panel navigasi, silakan pilih **Peran** lalu pilih **Buat peran**.
1. Pilih tipe ** Akun AWS peran**.
1. Untuk **Account ID, ketik** **Originating** Account ID.
Tutorial ini menggunakan contoh ID akun **111111111111** untuk akun **Originating**. Anda harus menggunakan ID akun yang valid. Jika Anda menggunakan ID akun yang tidak valid, seperti **111111111111**, IAM tidak mengizinkan Anda membuat peran baru.
Untuk saat ini, Anda tidak perlu memerlukan ID eksternal, atau mewajibkan pengguna untuk memiliki Multi-Factor Authentication (MFA) untuk menjalankan peran tersebut. Biarkan opsi ini tidak dipilih. Untuk informasi selengkapnya, lihat [AWS Otentikasi multi-faktor di IAM](id_credentials_mfa.md).
1. Pilih **Berikutnya: Izin** untuk mengatur izin yang terkait dengan peran.
1. Pilih kotak centang di samping kebijakan yang Anda buat sebelumnya.
**Kiat**
Untuk **Filter**, pilih **Pelanggan berhasil** memfilter daftar agar hanya menyertakan kebijakan yang Anda buat. Ini menyembunyikan kebijakan yang AWS dibuat dan membuatnya lebih mudah untuk menemukan yang Anda butuhkan.
Lalu, pilih **Selanjutnya**.
1. (Opsional) Tambahkan metadata ke peran dengan melampirkan tag sebagai pasangan nilai kunci. Untuk informasi selengkapnya tentang menggunakan tanda di IAM, lihat [Tag untuk AWS Identity and Access Management sumber daya](id_tags.md).
1. (Opsional) Untuk **Deskripsi**, masukkan deskripsi untuk peran baru ini.
1. Setelah meninjau peran, klik **Buat peran**.
Peran `UpdateData` muncul di daftar peran.
Sekarang Anda harus mendapatkan Nama Sumber Daya Amazon (ARN) dari peran tersebut, pengidentifikasi unik untuk peran tersebut. Saat Anda mengubah peran Pengembang di akun Originating, Anda menentukan peran ARN dari akun Tujuan untuk memberikan atau menolak izin.
**Untuk mendapatkan ARN untuk UpdateData**
1. Di panel navigasi konsol IAM, pilih **Peran**.
1. Dalam daftar peran, pilih peran `UpdateData`.
1. Di bagian **Ringkasan** di panel perincian, salin nilai **ARN Peran**.
Akun Tujuan memiliki ID akun 99999999999999, jadi peran ARN adalah. `arn:aws:iam::999999999999:role/UpdateData` Pastikan Anda memberikan Akun AWS ID asli untuk akun Tujuan.
Pada titik ini, Anda telah membangun kepercayaan antara akun **Tujuan** dan **Asal**. Anda melakukan ini dengan membuat peran di akun **Tujuan** yang mengidentifikasi akun **Originating** sebagai prinsipal tepercaya. Anda juga menentukan apa yang dapat dilakukan oleh pengguna yang beralih ke `UpdateData` peran tersebut.
Selanjutnya, ubah izin untuk peran Pengembang.
## Berikan akses ke peran tersebut
Pada titik ini, baik Analis dan Pengembang memiliki izin yang memungkinkan mereka mengelola data di akun **Originating**. Gunakan langkah-langkah berikut yang diperlukan untuk menambahkan izin agar dapat beralih ke peran.
**Untuk memodifikasi peran Pengembang agar mereka dapat beralih ke UpdateData peran**
1. Masuk sebagai administrator di akun **Originating**, dan buka konsol IAM.
1. Pilih **Peran**, lalu pilih **Pengembang**.
1. Pilih tab **Permissions** (Izin), pilih **Add permissions** (Tambahkan izin), lalu pilih **Create inline policy** (Membuat kebijakan inline).
1. Pilih tab **JSON**.
1. Tambahkan pernyataan kebijakan berikut untuk mengizinkan `AssumeRole` tindakan pada `UpdateData` peran di akun Tujuan. Pastikan bahwa Anda mengubah *DESTINATION-ACCOUNT-ID* `Resource` elemen ke Akun AWS ID aktual dari akun Tujuan.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
`Allow`Efeknya secara eksplisit memungkinkan grup Pengembang mengakses `UpdateData` peran di akun Tujuan. Setiap pengembang yang mencoba mengakses peran berhasil.
1. Pilih **Tinjau kebijakan**.
1. Ketik **Nama** seperti**allow-assume-S3-role-in-destination**.
1. Pilih **Buat kebijakan**.
Di sebagian besar lingkungan, Anda mungkin tidak memerlukan prosedur berikut. Namun, jika Anda menggunakan PowerUserAccess izin, maka beberapa grup mungkin sudah dapat beralih peran. Prosedur berikut menunjukkan cara menambahkan `"Deny"` izin ke grup Analis untuk memastikan bahwa mereka tidak dapat mengambil peran tersebut. Jika Anda tidak memerlukan prosedur ini di lingkungan Anda, maka kami sarankan Anda tidak menambahkannya. `"Deny"`izin membuat gambaran perizinan keseluruhan lebih rumit untuk dikelola dan dipahami. Gunakan `"Deny"` izin hanya jika Anda tidak memiliki opsi yang lebih baik.
**Untuk memodifikasi peran Analis untuk menolak izin untuk mengambil `UpdateData` peran**
1. Pilih **Peran**, lalu pilih **Analis**.
1. Pilih tab **Permissions** (Izin), pilih **Add permissions** (Tambahkan izin), lalu pilih **Create inline policy** (Membuat kebijakan inline).
1. Pilih tab **JSON**.
1. Tambahkan pernyataan kebijakan berikut untuk menolak tindakan `AssumeRole` di peran `UpdateData`. Pastikan bahwa Anda mengubah *DESTINATION-ACCOUNT-ID* `Resource` elemen ke Akun AWS ID aktual dari akun Tujuan.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
`Deny`Efeknya secara eksplisit menyangkal akses grup Analis ke `UpdateData` peran dalam akun Tujuan. Setiap analis yang mencoba mengakses peran menerima pesan yang ditolak akses.
1. Pilih **Tinjau kebijakan**.
1. Ketik **Nama** seperti**deny-assume-S3-role-in-destination**.
1. Pilih **Buat kebijakan**.
Peran Pengembang sekarang memiliki izin untuk menggunakan `UpdateData` peran di akun Tujuan. Peran analis dicegah dari menggunakan `UpdateData` peran tersebut.
Selanjutnya, Anda dapat melihat bagaimana David, seorang pengembang, dapat mengakses `amzn-s3-demo-bucket-shared-container` bucket di akun Tujuan. David dapat mengakses bucket dari Konsol Manajemen AWS, the AWS CLI, atau AWS API.
## Akses uji dengan mengalihkan peran
Setelah menyelesaikan dua langkah pertama tutorial ini, Anda memiliki peran yang memberikan akses ke sumber daya di akun **Tujuan**. Anda juga memiliki satu peran di akun **Originating** dengan pengguna diizinkan untuk menggunakan peran itu. Langkah ini membahas cara menguji peralihan ke peran itu dari Konsol Manajemen AWS, the AWS CLI, dan AWS API.
Untuk mendapatkan bantuan terkait masalah umum yang mungkin Anda temui saat bekerja dengan peran IAM, lihat[Memecahkan masalah peran IAM](troubleshoot_roles.md).
### Beralih peran (konsol)
Jika David perlu memperbarui data di akun **Destination** di Konsol Manajemen AWS, ia dapat melakukannya dengan menggunakan **Switch Role**. Dia menentukan ID akun atau alias dan nama peran, dan izinnya segera dialihkan kepada mereka yang diizinkan oleh peran tersebut. Dia kemudian dapat menggunakan konsol untuk bekerja dengan `amzn-s3-demo-bucket-shared-container` ember, tetapi tidak dapat bekerja dengan sumber daya lain di **Destination**. **Sementara David menggunakan peran itu, dia juga tidak dapat memanfaatkan hak istimewa penggunanya di akun Originating.** Itu karena hanya satu set izin yang dapat berlaku pada satu waktu.
IAM menyediakan dua cara yang dapat digunakan David untuk masuk ke halaman **Switch Role**:
+ David menerima tautan dari administrator mereka yang menunjuk ke konfigurasi Switch Role yang telah ditentukan sebelumnya. Tautan ini diberikan ke administrator di halaman terakhir dari panduan **Buat peran** atau pada halaman **Ringkasan Peran** untuk peran lintas akun. Memilih tautan ini membawa David ke halaman **Alihkan Peran** dengan bidang **ID Akun** dan **Nama peran** yang sudah diisi. Yang perlu dilakukan David adalah memilih **Switch Roles**.
+ Administrator tidak mengirim tautan di surel, tetapi mengirim nilai **ID Akun** dan **Nama Peran**. Untuk beralih peran, David harus memasukkan nilai secara manual. Hal ini digambarkan dalam prosedur berikut.
**Untuk mengambil peran**
1. David masuk ke Konsol Manajemen AWS menggunakan pengguna normalnya di akun **Originating**.
1. Mereka memilih tautan yang dikirim melalui email administrator kepada mereka. Ini membawa David ke halaman **Beralih Peran** dengan ID akun atau alias dan informasi nama peran yang sudah diisi.
— atau —
David memilih nama mereka (menu Identity) pada bilah navigasi, dan kemudian memilih **Switch** Roles.
Jika ini adalah pertama kalinya David mencoba mengakses halaman Switch Role dengan cara ini, dia pertama kali mendarat di halaman **Switch Role** yang dijalankan pertama kali. Halaman ini memberikan informasi tambahan tentang bagaimana peralihan peran dapat memungkinkan pengguna untuk mengelola sumber daya Akun AWS. David harus memilih **Switch Role** di halaman ini untuk menyelesaikan sisa prosedur ini.
1. Selanjutnya, untuk mengakses peran, David harus secara manual mengetikkan nomor ID akun Tujuan (`999999999999`) dan nama peran (`UpdateData`).
Selain itu, David ingin memantau peran dan izin terkait yang saat ini aktif di IAM. Untuk melacak informasi ini, dia mengetik `Destination` di kotak teks **Display Nama** (Nama Tampilan), memilih opsi warna merah, lalu memilih **Switch Role** (Alihkan Peran).
1. Sekarang, David dapat menggunakan konsol Amazon S3 untuk bekerja menggunakan bucket Amazon S3 atau sumber daya lain yang peran `UpdateData`nya memiliki izin.
1. Setelah selesai, David dapat kembali ke izin aslinya. Untuk melakukan itu, mereka memilih nama tampilan peran **Tujuan** pada bilah navigasi dan kemudian memilih **Kembali ke David @ 1111111111**.
1. Lain kali David ingin beralih peran dan memilih menu **Identitas** di bilah navigasi, dia melihat entri Tujuan masih ada dari terakhir kali. Dia cukup memilih entri itu untuk segera beralih peran tanpa memasukkan kembali ID akun dan nama peran.
### Beralih peran (AWS CLI)
Jika David perlu bekerja di lingkungan **Tujuan** di baris perintah, dia dapat melakukannya dengan menggunakan file [AWS CLI](https://aws.amazon.com/cli/). Dia menjalankan perintah `aws sts assume-role` dan meneruskan peran ARN untuk mendapatkan kredensial keamanan sementara untuk peran tersebut. Dia kemudian mengonfigurasi kredensil tersebut dalam variabel lingkungan sehingga AWS CLI perintah selanjutnya bekerja menggunakan izin peran. Sementara David menggunakan peran tersebut, ia tidak dapat menggunakan hak istimewa penggunanya di akun **Originating**, karena hanya satu set izin yang dapat berlaku pada satu waktu.
Perhatikan bahwa semua access key dan token hanyalah contoh dan tidak dapat digunakan seperti yang ditunjukkan. Ganti dengan nilai yang sesuai dari lingkungan langsung Anda.
**Untuk mengambil peran**
1. David membuka jendela command prompt, dan mengonfirmasi bahwa AWS CLI klien bekerja dengan menjalankan perintah:
```
aws help
```
**catatan**
Lingkungan default David menggunakan kredensial pengguna `David` dari profil default yang ia buat dengan perintah `aws configure`. Untuk informasi lebih lanjut, lihat [Mengonfigurasi AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) di *Panduan Pengguna AWS Command Line Interface *.
1. Dia memulai proses peralihan peran dengan menjalankan perintah berikut untuk beralih ke `UpdateData` peran di akun **Tujuan**. Dia menerima peran ARN dari administrator yang menciptakan peran tersebut. Perintah ini mengharuskan Anda memberikan nama sesi, Anda juga dapat memilih teks apa pun yang Anda suka untuk itu.
```
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
```
David kemudian melihat hal-hal berikut di output:
```
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
```
1. David melihat tiga bagian yang mereka butuhkan di bagian Credentials dari output.
+ `AccessKeyId`
+ `SecretAccessKey`
+ `SessionToken`
David perlu mengkonfigurasi AWS CLI lingkungan untuk menggunakan parameter ini dalam panggilan berikutnya. Untuk informasi tentang berbagai cara mengonfigurasi kredensial Anda, lihat [Mengonfigurasi AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence). Anda tidak dapat menggunakan perintah `aws configure` karena ia tindak mendukung perekaman token sesi. Namun, Anda dapat memasukkan informasi secara manual ke dalam file konfigurasi. Karena ini adalah kredensial sementara dengan waktu kedaluwarsa yang relatif singkat, paling mudah menambahkannya ke lingkungan sesi baris perintah Anda saat ini.
1. Untuk menambahkan tiga nilai ke lingkungan, David memotong dan menempelkan output langkah sebelumnya ke perintah berikutnya. Anda mungkin ingin memotong dan menempel ke dalam editor teks sederhana untuk mengatasi masalah line wrap dalam output token sesi. Ia harus ditambahkan sebagai satu string panjang, meskipun line wrap ditampilkan di sini untuk kejelasan.
Contoh berikut menunjukkan perintah yang diberikan di lingkungan Windows, di mana “set” adalah perintah untuk membuat variabel lingkungan. Di komputer Linux atau macOS, Anda akan menggunakan perintah “ekspor” sebagai gantinya. Semua bagian contoh lainnya valid di ketiga lingkungan.
Untuk detail tentang menggunakan Alat untuk Windows Powershell, lihat [Beralih ke peran IAM (Alat untuk Windows PowerShell)](id_roles_use_switch-role-twp.md)
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
```
Pada titik ini, setiap perintah berikut dijalankan di bawah izin peran yang diidentifikasi oleh kredensial tersebut. Dalam kasus David, peran `UpdateData`.
**penting**
Anda dapat menyimpan pengaturan konfigurasi dan kredensional yang sering digunakan dalam file yang dikelola oleh file. AWS CLI Untuk informasi selengkapnya, lihat [Menggunakan file konfigurasi dan kredensial yang ada](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing) di *AWS Command Line Interface Panduan Pengguna*.
1. Jalankan perintah untuk mengakses sumber daya di akun Tujuan. Dalam contoh ini, David mencantumkan isi bucket S3 mereka dengan perintah berikut.
```
aws s3 ls s3://shared-container
```
Karena nama bucket Amazon S3 unik secara universal, tidak perlu menentukan ID akun yang memiliki bucket. Untuk mengakses sumber daya untuk AWS layanan lain, lihat AWS CLI dokumentasi untuk layanan tersebut untuk perintah dan sintaks yang diperlukan untuk mereferensikan sumber dayanya.
### Menggunakan AssumeRole (AWS API)
Ketika David perlu membuat pembaruan ke akun **Tujuan** dari kode, dia membuat `AssumeRole` panggilan untuk mengambil `UpdateData` peran. Panggilan mengembalikan kredensi sementara yang dapat dia gunakan untuk mengakses `amzn-s3-demo-bucket-shared-container` bucket di akun **Tujuan**. Dengan kredensial tersebut, David dapat melakukan panggilan API untuk memperbarui bucket `amzn-s3-demo-bucket-shared-container`. **Namun, dia tidak dapat melakukan panggilan API untuk mengakses sumber daya lain di akun **Tujuan**, meskipun dia memiliki izin pengguna daya di akun Originating.**
**Untuk mengambil peran**
1. David memanggil `AssumeRole` sebagai bagian dari aplikasi. Mereka harus menentukan `UpdateData` ARN:. `arn:aws:iam::999999999999:role/UpdateData`
Respond dari panggilan `AssumeRole` mencakup kredensial sementara dengan `AccessKeyId` dan `SecretAccessKey`. Informasi ini juga mencakup waktu `Expiration` yang menunjukkan kapan kredensial kedaluwarsa dan Anda harus meminta yang baru. Saat Anda mengatur rantai peran dengan AWS SDK, banyak penyedia kredensi secara otomatis menyegarkan kredensil sebelum kedaluwarsa.
1. Dengan kredensial sementara, David membuat panggilan `s3:PutObject` untuk memperbarui bucket `amzn-s3-demo-bucket-shared-container`. Mereka akan meneruskan kredensil ke panggilan API sebagai parameter. `AuthParams` Karena kredenal peran sementara hanya memiliki akses baca dan tulis ke `amzn-s3-demo-bucket-shared-container` bucket, tindakan lain apa pun di akun Tujuan ditolak.
Untuk contoh kode (menggunakan Python), lihat [Beralih ke peran IAM (AWS API)](id_roles_use_switch-role-api.md).
## Sumber daya tambahan
Sumber daya berikut dapat membantu Anda mempelajari lebih lanjut tentang topik dalam tutorial ini:
+ Untuk informasi selengkapnya tentang pengguna IAM, lihat[Identitas IAM](id.md).
+ Untuk informasi selengkapnya tentang bucket Amazon S3, lihat [Membuat Bucket di Panduan](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) Pengguna *Layanan Penyimpanan Sederhana Amazon*.
+ Untuk mempelajari apakah prinsip di akun di luar zona kepercayaan (organisasi atau akun tepercaya) memiliki akses untuk menjalankan peran Anda, lihat [Apa yang dimaksud dengan Penganalisis Akses IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
## Ringkasan
Anda telah menyelesaikan tutorial akses API lintas akun. Anda menciptakan peran untuk membangun kepercayaan dengan akun lainnya dan menetapkan tindakan apa yang dapat dilakukan oleh entitas tepercaya. Kemudian, Anda mengubah kebijakan peran untuk mengontrol pengguna IAM mana yang dapat mengakses peran tersebut. Akibatnya, pengembang dari akun **Originating** dapat melakukan pembaruan ke `amzn-s3-demo-bucket-shared-container` bucket di akun **Destination** dengan menggunakan kredensi sementara.