Praktik terbaik kebijakan Batasan otorisasi tingkat sumber daya Menggunakan konsol Mengizinkan pengguna melihat izin mereka sendiri Akses tabel hanya-baca Filter tabel Akses meja penuh Awalan nama dengan tolak Contoh kontrol akses menggunakan tag Tolak akses menggunakan tag Gunakan tag dengan operasi API daftar dan batch Buat kebijakan yang mengontrol setelan menggunakan tombol kondisi Menolak identitas kemampuan untuk membuat sesi pratinjau data

Contoh kebijakan berbasis identitas untuk Glue AWS

Secara default, pengguna dan peran tidak memiliki izin untuk membuat atau memodifikasi sumber daya AWS Glue. Mereka juga tidak dapat melakukan tugas dengan menggunakan AWS Management Console, AWS Command Line Interface (AWS CLI), atau AWS API. Untuk memberikan izin kepada pengguna untuk melakukan tindakan di sumber daya yang mereka perlukan, administrator IAM dapat membuat kebijakan IAM. Administrator kemudian dapat menambahkan kebijakan IAM ke peran, dan pengguna dapat mengambil peran.

Untuk mempelajari cara membuat kebijakan berbasis identitas IAM dengan menggunakan contoh dokumen kebijakan JSON ini, lihat Membuat kebijakan IAM (konsol) di Panduan Pengguna IAM.

Untuk detail tentang tindakan dan jenis sumber daya yang ditentukan oleh AWS Glue, termasuk format ARNs untuk setiap jenis sumber daya, lihat Kunci tindakan, sumber daya, dan kondisi untuk AWS Glue dalam Referensi Otorisasi Layanan.

catatan

Contoh yang diberikan di bagian ini semuanya menggunakan us-west-2 Wilayah. Anda dapat menggantinya dengan AWS Wilayah yang ingin Anda gunakan.

Topik

Praktik terbaik kebijakan
Izin tingkat sumber daya hanya berlaku untuk objek tertentu AWS Glue
Menggunakan konsol AWS Glue
Mengizinkan pengguna melihat izin mereka sendiri
Berikan izin hanya-baca ke tabel
Filter tabel dengan GetTables izin
Berikan akses penuh ke tabel dan semua partisi
Kontrol akses dengan awalan nama dan penolakan eksplisit
Berikan akses menggunakan tag
Tolak akses menggunakan tag
Gunakan tag dengan operasi API daftar dan batch
Pengaturan kontrol menggunakan tombol kondisi atau tombol konteks
Menolak identitas kemampuan untuk membuat sesi pratinjau data

Praktik terbaik kebijakan

Kebijakan berbasis identitas menentukan apakah seseorang dapat membuat, mengakses, atau menghapus sumber daya AWS Glue di akun Anda. Tindakan ini membuat Akun AWS Anda dikenai biaya. Ketika Anda membuat atau mengedit kebijakan berbasis identitas, ikuti panduan dan rekomendasi ini:

Mulailah dengan kebijakan AWS terkelola dan beralih ke izin hak istimewa paling sedikit — Untuk mulai memberikan izin kepada pengguna dan beban kerja Anda, gunakan kebijakan AWS terkelola yang memberikan izin untuk banyak kasus penggunaan umum. Mereka tersedia di Anda Akun AWS. Kami menyarankan Anda mengurangi izin lebih lanjut dengan menentukan kebijakan yang dikelola AWS pelanggan yang khusus untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat Kebijakan yang dikelola AWS atau Kebijakan yang dikelola AWS untuk fungsi tugas dalam Panduan Pengguna IAM.
Menerapkan izin dengan hak akses paling rendah – Ketika Anda menetapkan izin dengan kebijakan IAM, hanya berikan izin yang diperlukan untuk melakukan tugas. Anda melakukannya dengan mendefinisikan tindakan yang dapat diambil pada sumber daya tertentu dalam kondisi tertentu, yang juga dikenal sebagai izin dengan hak akses paling rendah. Untuk informasi selengkapnya tentang cara menggunakan IAM untuk mengajukan izin, lihat Kebijakan dan izin dalam IAM dalam Panduan Pengguna IAM.
Gunakan kondisi dalam kebijakan IAM untuk membatasi akses lebih lanjut – Anda dapat menambahkan suatu kondisi ke kebijakan Anda untuk membatasi akses ke tindakan dan sumber daya. Sebagai contoh, Anda dapat menulis kondisi kebijakan untuk menentukan bahwa semua permintaan harus dikirim menggunakan SSL. Anda juga dapat menggunakan ketentuan untuk memberikan akses ke tindakan layanan jika digunakan melalui yang spesifik Layanan AWS, seperti AWS CloudFormation. Untuk informasi selengkapnya, lihat Elemen kebijakan JSON IAM: Kondisi dalam Panduan Pengguna IAM.
Gunakan IAM Access Analyzer untuk memvalidasi kebijakan IAM Anda untuk memastikan izin yang aman dan fungsional – IAM Access Analyzer memvalidasi kebijakan baru dan yang sudah ada sehingga kebijakan tersebut mematuhi bahasa kebijakan IAM (JSON) dan praktik terbaik IAM. IAM Access Analyzer menyediakan lebih dari 100 pemeriksaan kebijakan dan rekomendasi yang dapat ditindaklanjuti untuk membantu Anda membuat kebijakan yang aman dan fungsional. Untuk informasi selengkapnya, lihat Validasi kebijakan dengan IAM Access Analyzer dalam Panduan Pengguna IAM.
Memerlukan otentikasi multi-faktor (MFA) - Jika Anda memiliki skenario yang mengharuskan pengguna IAM atau pengguna root di Anda, Akun AWS aktifkan MFA untuk keamanan tambahan. Untuk meminta MFA ketika operasi API dipanggil, tambahkan kondisi MFA pada kebijakan Anda. Untuk informasi selengkapnya, lihat Amankan akses API dengan MFA dalam Panduan Pengguna IAM.

Untuk informasi selengkapnya tentang praktik terbaik dalam IAM, lihat Praktik terbaik keamanan di IAM dalam Panduan Pengguna IAM.

Izin tingkat sumber daya hanya berlaku untuk objek tertentu AWS Glue

Anda hanya dapat menentukan kontrol berbutir halus untuk objek tertentu di. AWS Glue Oleh karena itu, Anda harus menulis kebijakan IAM klien Anda sehingga operasi API yang mengizinkan Amazon Resource Names (ARNs) untuk Resource pernyataan tidak dicampur dengan operasi API yang tidak mengizinkan ARNs.

Misalnya, kebijakan IAM berikut memungkinkan operasi API untuk GetClassifier dan GetJobRun. Ini mendefinisikan Resource sebagai * karena AWS Glue tidak memungkinkan ARNs untuk pengklasifikasi dan pekerjaan berjalan. Karena ARNs diizinkan untuk operasi API tertentu seperti GetDatabase danGetTable, ARNs dapat ditentukan di paruh kedua kebijakan.

Untuk daftar AWS Glue objek yang memungkinkan ARNs, lihatMenentukan Sumber Daya AWS Glue ARNs.

Menggunakan konsol AWS Glue

Untuk mengakses konsol AWS Glue, Anda harus memiliki set izin minimum. Izin ini harus memungkinkan Anda untuk membuat daftar dan melihat detail tentang sumber daya AWS Glue di Anda Akun AWS. Jika Anda membuat kebijakan berbasis identitas yang lebih ketat daripada izin minimum yang diperlukan, konsol tidak akan berfungsi sebagaimana mestinya untuk entitas (pengguna atau peran) dengan kebijakan tersebut.

Anda tidak perlu mengizinkan izin konsol minimum untuk pengguna yang melakukan panggilan hanya ke AWS CLI atau AWS API. Sebagai gantinya, izinkan akses hanya ke tindakan yang sesuai dengan operasi API yang coba mereka lakukan.

Untuk memastikan bahwa pengguna dan peran masih dapat menggunakan konsol AWS Glue, lampirkan juga AWS Glue ConsoleAccess atau kebijakan ReadOnly AWS terkelola ke entitas. Untuk informasi selengkapnya, lihat Menambah izin untuk pengguna dalam Panduan Pengguna IAM.

Agar pengguna dapat bekerja dengan AWS Glue konsol, pengguna tersebut harus memiliki serangkaian izin minimum yang memungkinkan mereka bekerja dengan AWS Glue sumber daya untuk AWS akun mereka. Selain izin AWS Glue ini, konsol memerlukan izin dari layanan berikut:

Izin CloudWatch Log Amazon untuk menampilkan log.
AWS Identity and Access Management (IAM) izin untuk membuat daftar dan meneruskan peran.
AWS CloudFormation izin untuk bekerja dengan tumpukan.
Izin Amazon Elastic Compute Cloud (Amazon EC2) untuk daftar VPCs, subnet, grup keamanan, instance, dan objek lainnya.
Izin Amazon Simple Storage Service (Amazon S3) untuk mencantumkan bucket dan objek, dan untuk mengambil dan menyimpan skrip.
Izin Amazon Redshift untuk bekerja dengan klaster.
Izin Amazon Relational Database Service (Amazon RDS) untuk mencantumkan instans.

Untuk informasi selengkapnya tentang izin yang diperlukan pengguna untuk melihat dan bekerja dengan AWS Glue konsol, lihatLangkah 3: Lampirkan kebijakan ke pengguna atau grup yang mengakses AWS Glue.

Jika Anda membuat kebijakan IAM yang lebih ketat daripada izin minimum yang diperlukan, konsol tidak akan berfungsi sebagaimana mestinya bagi pengguna dengan kebijakan IAM tersebut. Untuk memastikan bahwa pengguna tersebut masih dapat menggunakan AWS Glue konsol, lampirkan juga kebijakan AWSGlueConsoleFullAccess terkelola seperti yang dijelaskan dalamAWS kebijakan terkelola (standar) untuk AWS Glue.

Mengizinkan pengguna melihat izin mereka sendiri

Contoh ini menunjukkan cara membuat kebijakan yang mengizinkan pengguna IAM melihat kebijakan inline dan terkelola yang dilampirkan ke identitas pengguna mereka. Kebijakan ini mencakup izin untuk menyelesaikan tindakan ini di konsol atau menggunakan API atau secara terprogram. AWS CLI AWS


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

Berikan izin hanya-baca ke tabel

Kebijakan ini memberikan izin baca-saja ke sebuah tabel books dalam basis data db1. Untuk informasi selengkapnya tentang sumber daya Amazon Resource Names (ARNs), lihatKatalog Data ARNs.

Kebijakan ini memberikan izin baca-saja ke tabel bernama books dalam basis data bernama db1. Untuk memberikan Get izin ke tabel, izin ke katalog dan sumber daya database juga diperlukan.

Kebijakan berikut memberikan izin minimum yang diperlukan untuk membuat tabel tb1 dalam basis data db1:

Filter tabel dengan GetTables izin

Asumsikan bahwa ada tiga tabel—yaitu, customers, stores, dan store_sales—dalam basis data db1. Kebijakan berikut memberikan izin GetTables untuk stores dan store_sales, tetapi tidak untuk customers. Ketika Anda memanggil GetTables dengan kebijakan ini, hasilnya hanya berisi dua tabel yang mendapat otorisasi (tabel customers tidak dikembalikan).

Anda dapat menyederhanakan kebijakan sebelumnya dengan menggunakan store* untuk mencocokkan dengan nama tabel yang dimulai dengan store.

Demikian pula, menggunakan /db1/* untuk mencocokkan dengan semua tabel di db1, kebijakan berikut memberikan akses GetTables ke semua tabel di db1.

Jika tidak ada ARN tabel yang disediakan, panggilan untuk GetTables berhasil, tetapi ia hanya mengembalikan daftar kosong.

Jika basis data ARN tidak ada dalam kebijakan, maka panggilan ke GetTables akan gagal dengan sebuah AccessDeniedException.

Berikan akses penuh ke tabel dan semua partisi

Kebijakan ini memberikan semua izin pada sebuah tabel bernama books dalam basis data db1. Ini termasuk izin baca dan tulis pada tabel itu sendiri, pada versi yang diarsipkannya, dan pada semua partisinya.

Kebijakan sebelumnya dapat disederhanakan dalam prakteknya.

Perhatikan bahwa kedetailan minimum dari kontrol akses detail adalah pada tingkat tabel. Ini berarti bahwa Anda tidak dapat memberikan akses kepada pengguna ke beberapa partisi dalam sebuah tabel, tetapi tidak dalam tabel lainnya, atau beberapa kolom tabel, tetapi tidak lainnya. Seorang pengguna memiliki akses ke semua tabel, atau tidak sama sekali.

Kontrol akses dengan awalan nama dan penolakan eksplisit

Dalam contoh ini, misalkan database dan tabel di Katalog Data AWS Glue Anda diatur menggunakan awalan nama. Basis data dalam tahap pengembangan memiliki nama prefiks dev-, dan yang dalam produksi memiliki prefiks nama prod-. Anda dapat menggunakan kebijakan berikut untuk memberikan pengembang akses penuh ke semua database, tabel UDFs, dan sebagainya, yang memiliki dev- awalan. Namun Anda memberikan akses baca-saja ke semua yang memiliki prefiks prod-.

JSON


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DevAndProdFullAccess",
            "Effect": "Allow",
            "Action": [
                "glue:*Database*",
                "glue:*Table*",
                "glue:*Partition*",
                "glue:*UserDefinedFunction*",
                "glue:*Connection*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",
                "arn:aws:glue:us-west-2:123456789012:database/dev-*",
                "arn:aws:glue:us-west-2:123456789012:database/prod-*",
                "arn:aws:glue:us-west-2:123456789012:table/dev-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/dev-*",
                "arn:aws:glue:us-west-2:123456789012:table/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/dev-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/dev-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:connection/dev-*",
                "arn:aws:glue:us-west-2:123456789012:connection/prod-*"
            ]
        },
        {
            "Sid": "ProdWriteDeny",
            "Effect": "Deny",
            "Action": [
                "glue:*Create*",
                "glue:*Update*",
                "glue:*Delete*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:database/prod-*",
                "arn:aws:glue:us-west-2:123456789012:table/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:connection/prod-*"
            ]
        }
    ]
}

Pernyataan kedua dalam kebijakan sebelumnya menggunakan deny eksplisit. Anda dapat menggunakan deny eksplisit untuk menimpa izin allow yang diberikan kepada prinsipal utama. Hal ini memungkinkan Anda mengunci akses ke sumber daya penting dan mencegah kebijakan lain memberikan akses kepada mereka secara tidak sengaja.

Dalam contoh sebelumnya, meskipun pernyataan pertama memberikan akses penuh ke sumber daya prod-, pernyataan kedua secara eksplisit mencabut akses tulis ke mereka, yang hanya menyisakan akses baca ke sumber daya prod-.

Berikan akses menggunakan tag

Misalnya, anggaplah Anda ingin membatasi akses ke sebuah pemicu t2 ke pengguna tertentu bernama Tom di akun Anda. Semua pengguna lain, termasuk Sam, memiliki akses ke pemicu t1. Pemicu t1 dan t2 memiliki properti berikut.


aws glue get-triggers
{
    "Triggers": [
        {
            "State": "CREATED",
            "Type": "SCHEDULED",
            "Name": "t1",
            "Actions": [
                {
                    "JobName": "j1"
                }
            ],
            "Schedule": "cron(0 0/1 * * ? *)"
        },
        {
            "State": "CREATED",
            "Type": "SCHEDULED",
            "Name": "t2",
            "Actions": [
                {
                    "JobName": "j1"
                }
            ],
            "Schedule": "cron(0 0/1 * * ? *)"
        }
    ]
}

AWS GlueAdministrator melampirkan nilai tag Tom (aws:ResourceTag/Name": "Tom") untuk memicut2. AWS GlueAdministrator juga memberi Tom kebijakan IAM dengan pernyataan kondisi berdasarkan tag. Akibatnya, Tom hanya dapat menggunakan AWS Glue operasi yang bekerja pada sumber daya dengan nilai tagTom.

Ketika Tom mencoba mengakses pemicu t1, ia menerima pesan akses ditolak. Sementara itu, ia dapat berhasil mengambil pemicu t2.


aws glue get-trigger --name t1

An error occurred (AccessDeniedException) when calling the GetTrigger operation: User: Tom is not authorized to perform: glue:GetTrigger on resource: arn:aws:glue:us-east-1:123456789012:trigger/t1

aws glue get-trigger --name t2
{
    "Trigger": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j1"
            }
        ],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

Tom tidak dapat menggunakan operasi GetTriggers API jamak untuk membuat daftar pemicu karena operasi ini tidak mendukung pemfilteran pada tag.

Untuk memberi Tom aksesGetTriggers, AWS Glue administrator membuat kebijakan yang membagi izin menjadi dua bagian. Satu bagian memungkinkan Tom mengakses semua pemicu dengan operasi API GetTriggers. Bagian yang lain memungkinkan Tom mengakses ke operasi API yang ditandai dengan nilai Tom. Dengan kebijakan ini, Tom diperbolehkan menggunakan akses GetTriggers dan GetTrigger ke pemicu t2.

Tolak akses menggunakan tag

Pendekatan kebijakan sumber daya lainnya adalah dengan secara eksplisit menolak akses ke sumber daya.

penting

Kebijakan penolakan eksplisit tidak berfungsi untuk operasi API jamak seperti. GetTriggers

Dalam contoh kebijakan berikut, semua operasi AWS Glue pekerjaan diperbolehkan. Namun, Effect pernyataan kedua secara eksplisit menolak akses ke pekerjaan yang ditandai dengan kunci dan nilai. Team Special

Ketika administrator melampirkan kebijakan berikut ke identitas, identitas dapat mengakses semua pekerjaan kecuali yang ditandai dengan Team kunci dan Special nilai.

Gunakan tag dengan operasi API daftar dan batch

Pendekatan ketiga untuk penulisan kebijakan sumber daya adalah dengan memungkinkan akses ke sumber daya menggunakan operasi API List untuk mencantumkan sumber daya untuk nilai tag. Kemudian, gunakan operasi API Batch yang sesuai untuk memungkinkan akses ke detail sumber daya tertentu. Dengan pendekatan ini, administrator tidak perlu mengizinkan akses ke operasi API GetCrawlers, GetDevEndpoints, GetJobs, atau GetTriggers majemuk. Sebaliknya, Anda dapat memungkinkan kemampuan untuk mencantumkan sumber daya dengan operasi API berikut:

ListCrawlers
ListDevEndpoints
ListJobs
ListTriggers

Dan, Anda dapat memungkinkan kemampuan untuk mendapatkan detail tentang masing-masing sumber daya dengan operasi API berikut:

BatchGetCrawlers
BatchGetDevEndpoints
BatchGetJobs
BatchGetTriggers

Sebagai administrator, untuk menggunakan pendekatan ini, Anda dapat melakukan hal berikut ini:

Tambahkan tag ke crawler, titik akhir pengembangan, tugas, dan pemicu Anda.
Tolak akses pengguna ke operasi API Get seperti GetCrawlers, GetDevEndponts, GetJobs, dan GetTriggers.
Untuk memungkinkan pengguna untuk mengetahui sumber daya yang ditandai yang mana yang mereka miliki aksesnya, memungkinkan akses pengguna ke operasi API List seperti ListCrawlers, ListDevEndponts, ListJobs, dan ListTriggers.
Tolak akses pengguna ke AWS Glue penandaan APIs, seperti TagResource danUntagResource.
Izinkan akses pengguna ke detail sumber daya dengan operasi API BatchGet seperti BatchGetCrawlers, BatchGetDevEndponts, BatchGetJobs, dan BatchGetTriggers.

Misalnya, saat memanggil operasi ListCrawlers, berikan nilai tag yang cocok dengan nama pengguna. Maka hasilnya adalah sebuah daftar crawler yang cocok dengan nilai tag yang disediakan. Berikan daftar nama BatchGetCrawlers untuk mendapatkan detail tentang setiap crawler dengan tag yang diberikan.

Misalnya, jika Tom hanya dapat mengambil detail pemicu yang ditandai, administrator dapat menambahkan tag ke pemicuTom, menolak akses ke operasi GetTriggers API ke semua penggunaTom, dan mengizinkan akses ke semua pengguna ke dan. ListTriggers BatchGetTriggers

Berikut ini adalah kebijakan sumber daya yang AWS Glue diberikan administrator kepada Tom. Di bagian pertama kebijakan, operasi AWS Glue API ditolak untukGetTriggers. Pada bagian kedua dari kebijakan tersebut, ListTriggers diperbolehkan untuk semua sumber daya. Namun demikian, di bagian ketiga, sumber daya yang ditandai dengan Tom tersebut diperbolehkan mengakses dengan akses BatchGetTriggers.

Dengan menggunakan pemicu yang sama seperti contoh sebelumnya, Tom dapat mengakses pemicu t2, tapi tidak pemicu t1. Contoh berikut menunjukkan hasil ketika Tom mencoba untuk mengakses t1 dan t2 dengan BatchGetTriggers.


aws glue batch-get-triggers --trigger-names t2
{
    "Triggers": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j2"
            }
        ],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

aws glue batch-get-triggers  --trigger-names t1

An error occurred (AccessDeniedException) when calling the BatchGetTriggers operation: No access to any requested resource.

Contoh berikut menunjukkan hasil ketika Tom mencoba untuk mengakses pemicu t2 dan pemicu t3 (yang tidak ada) dalam panggilan BatchGetTriggers yang sama. Perhatikan bahwa karena Tom memiliki akses ke pemicu t2 dan itu ada, hanya t2 yang dikembalikan. Meskipun Tom diperbolehkan untuk mengakses pemicu t3, namun pemicu t3 tidak ada, jadi t3 dikembalikan dalam respon dalam sebuah daftar "TriggersNotFound": [].


aws glue batch-get-triggers --trigger-names t2 t3
{
    "Triggers": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j2"
            }
        ],
        "TriggersNotFound": ["t3"],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

Pengaturan kontrol menggunakan tombol kondisi atau tombol konteks

Anda dapat menggunakan tombol kondisi atau kunci konteks saat memberikan izin untuk membuat dan memperbarui pekerjaan. Bagian-bagian ini membahas kunci:

Kebijakan kontrol yang mengontrol pengaturan menggunakan tombol kondisi
Kebijakan kontrol yang mengontrol setelan menggunakan tombol konteks

Kebijakan kontrol yang mengontrol pengaturan menggunakan tombol kondisi

AWS Glue menyediakan tiga kunci kondisi IAMglue:VpcIds,glue:SubnetIds, danglue:SecurityGroupIds. Anda dapat menggunakan kunci kondisi dalam kebijakan IAM saat memberikan izin untuk membuat dan memperbarui pekerjaan. Anda dapat menggunakan pengaturan ini untuk memastikan bahwa pekerjaan atau sesi tidak dibuat (atau diperbarui ke) untuk berjalan di luar lingkungan VPC yang diinginkan. Informasi pengaturan VPC bukanlah input langsung dari CreateJob permintaan, tetapi disimpulkan dari bidang “koneksi” pekerjaan yang menunjuk ke koneksi. AWS Glue

Contoh penggunaan

Buat koneksi tipe AWS Glue jaringan bernama "traffic-monitored-connection" dengan “ VpcId vpc-id1234" yang diinginkan,, dan. SubnetIds SecurityGroupIds

Tentukan kondisi kunci kondisi untuk CreateJob dan UpdateJob tindakan dalam kebijakan IAM.


{
  "Effect": "Allow",
  "Action": [
    "glue:CreateJob",
    "glue:UpdateJob"
  ],
  "Resource": [
    "*"
  ],
  "Condition": {
    "ForAnyValue:StringLike": {
      "glue:VpcIds": [
        "vpc-id1234"
      ]
    }
  }
}

Anda dapat membuat kebijakan IAM serupa untuk melarang membuat AWS Glue pekerjaan tanpa menentukan informasi koneksi.

Membatasi sesi pada VPCs

<123>Untuk menegakkan sesi yang dibuat agar berjalan dalam VPC tertentu, Anda membatasi izin peran dengan menambahkan Deny efek pada glue:CreateSession tindakan dengan syarat lem: vpc-id tidak sama dengan vpc-. Misalnya:


"Effect": "Deny",
"Action": [
    "glue:CreateSession"
 ],
"Condition": {
    "StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]} 
}

Anda juga dapat menerapkan sesi yang dibuat untuk dijalankan dalam VPC dengan menambahkan Deny efek pada glue:CreateSession tindakan dengan syarat bahwa glue:vpc-id adalah null. Misalnya:


{
    "Effect": "Deny",
    "Action": [
        "glue:CreateSession"
    ],
      "Condition": {
        "Null": {"glue:VpcIds": true}
    }
}, 
{
    "Effect": "Allow",
    "Action": [
        "glue:CreateSession"
    ],
    "Resource": ["*"]
}

Kebijakan kontrol yang mengontrol setelan menggunakan tombol konteks

AWS Glue menyediakan kunci konteks (glue:CredentialIssuingService= glue.amazonaws.com) untuk setiap sesi peran AWS Glue yang tersedia untuk pekerjaan dan titik akhir pengembang. Ini memungkinkan Anda untuk menerapkan kontrol keamanan untuk tindakan yang diambil oleh AWS Glue skrip. AWS Gluemenyediakan kunci konteks lain (glue:RoleAssumedBy=glue.amazonaws.com) untuk setiap sesi peran di mana AWS Glue melakukan panggilan ke AWS layanan lain atas nama pelanggan (bukan oleh job/dev titik akhir, tetapi langsung oleh AWS Glue layanan).

Contoh penggunaan

Tentukan izin bersyarat dalam kebijakan IAM dan lampirkan ke peran yang akan digunakan oleh pekerjaan. AWS Glue Ini memastikan tindakan tertentu allowed/denied didasarkan pada apakah sesi peran digunakan untuk lingkungan runtime AWS Glue pekerjaan.


{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
    "Condition": {
        "StringEquals": {
            "glue:CredentialIssuingService": "glue.amazonaws.com"
        }
    }
}

Menolak identitas kemampuan untuk membuat sesi pratinjau data

Bagian ini berisi contoh kebijakan IAM yang digunakan untuk menolak identitas kemampuan untuk membuat sesi pratinjau data. Lampirkan kebijakan ini ke identitas, yang terpisah dari peran yang digunakan oleh sesi pratinjau data selama dijalankan.


{
    "Sid": "DatapreviewDeny",
    "Effect": "Deny",
     "Action": [
           "glue:CreateSession"
     ],
     "Resource": [
          "arn:aws:glue:*:*:session/glue-studio-datapreview*"
      ]
 }

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

AWS Contoh kebijakan kontrol akses Glue

Contoh kebijakan berbasis sumber daya