Ohmyzsh: Plugin AWS mencoba mengambil peran secara manual

Dibuat pada 28 Okt 2020  ·  40Komentar  ·  Sumber: ohmyzsh/ohmyzsh

Jelaskan bugnya
Perintah asp dari plugin aws sekarang mengambil peran itu sendiri ketika role_arn didefinisikan di profil AWS.
Ini bukan bagaimana seharusnya bekerja; AWS CLI sangat mampu mengambil peran dengan cepat dan tidak mengekspos kredensial AWS ke variabel lingkungan.
Dilacak ke PR ini: https://github.com/ohmyzsh/ohmyzsh/pull/8419.

Saya tidak tahu apakah ini adalah kebutuhan khusus seputar MFA tetapi hanya memeriksa atribut role_arn tidak cukup untuk memicu peran asumsi "manual".

Mungkin @maksyms bisa berkomentar sebagai penulis PR.

Untuk Mereproduksi
Langkah-langkah untuk mereproduksi perilaku, misalnya:

  1. Aktifkan plugin ini 'aws'
  2. Miliki profil "myprofile" menggunakan role_arn
  3. Jalankan perintah 'asp myprofile'
  4. Fungsi mencoba untuk mengambil peran dan menetapkan kredensial ke variabel lingkungan

Perilaku yang diharapkan
Kecuali MFA diperlukan, asp seharusnya hanya mengatur variabel lingkungan AWS_PROFILE

Desktop (harap lengkapi informasi berikut):

  • OS / Distro: macOS
  • Pembaruan ohmyzsh terbaru?: Ya
  • Versi ZSH: 5.8
  • Emulator terminal: iTerm2

Komentar yang paling membantu

@wnkz

Saya tidak keberatan memiliki fungsi yang berbeda untuk MFA dan yang lainnya, tetapi saya tidak berpikir fungsi asp harus melampaui pengaturan variabel lingkungan dan harus tetap seperti itu karena alasan kompatibilitas.

Tidak begitu yakin tentang itu - tujuan asp adalah untuk mengganti profil, bukan untuk mengatur variabel lingkungan, bukan?

tetapi hanya memeriksa atribut role_arn tidak cukup untuk memicu peran asumsi "manual".

@wknz Mengapa Anda mengatakan itu? Bisakah Anda menyebutkan alasan lain untuk memiliki role_arn di konfigurasi profil Anda?

@maksyms Saya sangat bingung dengan pertanyaan Anda
Pernahkah Anda membaca https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html ?

role_arn + source_profile adalah pengaturan paling dasar untuk menggunakan peran dengan AWS CLI. Saya tidak sering menggunakannya tetapi dapat menangani MFA jika saya ingat dengan benar.
Dengan konfigurasi ini, AWS CLI secara otomatis mengambil peran yang dikonfigurasi di profil, menyimpan kredensial, dan memperbaruinya saat diperlukan.

Saat Anda menggunakan peran, AWS CLI menyimpan kredensial sementara secara lokal hingga masa berlakunya habis. Saat berikutnya Anda mencoba menggunakannya, AWS CLI mencoba memperbaruinya atas nama Anda.

Cara untuk memberitahu AWS CLI yang profil untuk penggunaan adalah melalui --profile bendera atau AWS_PROFILE variabel lingkungan.
IMHO, fungsi asp hanya digunakan untuk membuat daftar profil yang ada dan mengatur variabel lingkungan dengan mudah sehingga AWS CLI dapat melakukan sisa pekerjaan untuk Anda sebagaimana dimaksud .

Sekarang, dengan fungsi yang diperbarui, peran diasumsikan secara manual, kredensial disimpan dalam variabel lingkungan dan tidak pernah diperbarui. Selanjutnya, mengasumsikan peran langsung menyebabkan masalah dengan jenis konfigurasi lanjutan lainnya menggunakan credential_process atau AWS SSO dari CLI v2.

Saya benar-benar tidak ingin terdengar kasar tetapi perubahan ini hanya memberi saya masalah. Saya tidak benar-benar tahu apa yang membuat Anda melakukan ini dan ini mungkin kasus penggunaan yang sangat baik tetapi ini adalah perubahan yang melanggar bagi saya dan setidaknya harus diimplementasikan dalam fungsi baru tetapi tidak menggantikan yang sudah ada.

👋

Semua 40 komentar

Terima kasih atas laporan Anda. Saya akan menyelidiki dan kembali.

Pengaturan saya:

  1. Kredensial AWS di bawah profil, menggunakan asp profilename
  2. Menggunakan https://github.com/joepjoosten/aws-cli-mfa-oh-my-zsh untuk mengotentikasi dengan MFA
  3. Saat sekarang menggunakan asp otherprofile (di mana otherprofile memiliki role_arn dan source_profile diatur dalam kredensial) saya mendapatkan:
Assuming role arn:aws:iam::9999999999999:role/myrole using profile otherprofile

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::11111111111:user/original_user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::9999999999999:role/myrole
Switched to AWS Profile: otherprofile

Jadi itu mengganti profil saat gagal

Skrip yang benar-benar berfungsi (untuk ide), jika saya melakukannya aar otherprofile :

aar () {
    if [[ -z "$1" ]]
    then
        unset AWS_DEFAULT_PROFILE AWS_PROFILE AWS_EB_PROFILE
        echo AWS profile cleared.
        return
    fi
    local aws_profile_name=${1}
    local role_arn=$(aws configure --profile ${aws_profile_name} get role_arn)
    if [[ -z "$role_arn" ]]
    then
        echo Role ARN for profile \(${aws_profile_name}\) cannot be found.
        echo Please set the \'role_arn\' attribute on the profile.
        return 1
    fi
    local session_name="${aws_profile_name}-session"
    local credentials_output=$(aws sts assume-role --role-arn ${role_arn} --role-session-name ${session_name} --query '[Credentials.AccessKeyId,Credentials.SecretAccessKey,Credentials.SessionToken]' --output text | tr "\t" "\n")
    local credentials=("${(f)credentials_output}")
    local access_key_id=${credentials[1]}
    local secret_access_key=${credentials[2]}
    local session_token=${credentials[3]}
    aws configure --profile ${aws_profile_name} set aws_access_key_id ${access_key_id}
    aws configure --profile ${aws_profile_name} set aws_secret_access_key ${secret_access_key}
    aws configure --profile ${aws_profile_name} set aws_session_token ${session_token}
    export AWS_ACCESS_KEY_ID=${access_key_id}
    export AWS_SECRET_ACCESS_KEY=${secret_access_key}
    export AWS_SESSION_TOKEN=${session_token}
    export AWS_DEFAULT_PROFILE=${aws_profile_name}
    export AWS_PROFILE=${aws_profile_name}
    export AWS_EB_PROFILE=${aws_profile_name}
    echo Credentials set for AWS profile \(${aws_profile_name}\)
}

Saya tidak keberatan memiliki fungsi yang berbeda untuk MFA dan yang lainnya, tetapi saya tidak berpikir fungsi asp harus melampaui pengaturan variabel lingkungan dan harus tetap seperti itu karena alasan kompatibilitas.

@wnkz itulah yang terjadi dengan versi sebelumnya dari plugin AWS, itu diubah baru-baru ini (tidak yakin mengapa, saya hanya memperhatikannya ketika menarik cabang master)

@robvadai

Jadi itu mengganti profil saat gagal

Itu sebenarnya tidak mengubah profil - itu mengatur variabel lingkungan. Itu bisa melakukan penanganan kesalahan dengan lebih baik, cukup adil. Saya akan melihat apa yang bisa dilakukan.

@wnkz

Saya tidak keberatan memiliki fungsi yang berbeda untuk MFA dan yang lainnya, tetapi saya tidak berpikir fungsi asp harus melampaui pengaturan variabel lingkungan dan harus tetap seperti itu karena alasan kompatibilitas.

Tidak begitu yakin tentang itu - tujuan asp adalah untuk mengganti profil, bukan untuk mengatur variabel lingkungan, bukan?

tetapi hanya memeriksa atribut role_arn tidak cukup untuk memicu peran asumsi "manual".

@wknz Mengapa Anda mengatakan itu? Bisakah Anda menyebutkan alasan lain untuk memiliki role_arn di konfigurasi profil Anda?

@wknz Saya telah membaca kembali deskripsi Anda dan saya dapat mengonfirmasi bahwa ini bukan bug. Dengan asumsi peran IAM adalah cara AWS merekomendasikan mengamankan akses ke sumber daya Anda: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#delegate -using-roles

Jika bukan itu yang Anda inginkan, Anda cukup tepat mengisyaratkan solusi: hapus role_arn dari ~/.aws/config untuk profil yang tidak memerlukan asumsi peran.

Tetap saja itu tidak berfungsi setidaknya jika MFA diaktifkan yang seharusnya menjadi standar untuk semua orang.

Tetap saja itu tidak berfungsi setidaknya jika MFA diaktifkan yang seharusnya menjadi standar untuk semua orang.

@robvadai Saya sedang memeriksa kasus Anda sekarang. Idealnya, saya memilikinya di bug lain (karena kesimpulan pada yang asli ada di atas), tetapi saya akan memeriksanya.

Sementara itu, saya dapat memberi tahu Anda bahwa di perusahaan saya, lebih dari 20 insinyur berhasil menggunakannya dengan MFA. Jadi pasti ada sesuatu yang spesifik untuk pengaturan Anda, yang sedang saya periksa.

Saya menghargai itu, namun saya mencobanya di akun AWS untuk 2 perusahaan (saya seorang konsultan) dan tidak berfungsi untuk keduanya - ini adalah 2 perusahaan, terletak secara geografis di tempat yang berbeda dan staf yang sama sekali berbeda sehingga tidak mungkin orang yang sama mengatur akun AWS mereka.

@robvadai , saya sedang mencari. Sementara itu, apa kesamaan antara 2 perusahaan di mana Anda menjadi konsultan? Itu sebabnya saya ingin memeriksa bagaimana _you_ melakukannya. 👍

Sementara itu, berikut adalah tangkapan layar menggunakan plugin di salah satu dari 4 akun AWS saya yang berbeda:

image

Kecurigaan saya adalah kredensial kami diatur secara berbeda. Bisakah Anda membagikan ~/.aws/credentials dan ~/.aws/config untuk profil default dan dev_admin_cli ? Tentu saja ganti kunci akses dengan ABC dll.

@robvadai
Apakah ada kemungkinan Anda dapat membagikan ~/.aws/config , mengosongkan semua nomor akun dan nama perusahaan?

Ini milik saya, dari salah satu mesin, sebagai contoh:

image

:-D

Dan kredensial:

image

OK saya tidak menggunakan mfa_serial dan external_id apa itu? Masalah ini dapat diselesaikan dengan beberapa instruksi di README :)

@robvadai Anda mungkin benar tentang README.

Jadi mfa_serial adalah perangkat MFA terdaftar ARN untuk melakukan MFA. Jika tidak ada, skrip akan mengabaikannya.

Dan external_id hanyalah lapisan keamanan tambahan opsional - lapisan itu hanya diperlukan jika Anda ingin memiliki rahasia bersama tambahan antara siapa pun yang mengambil peran dan siapa pun yang mengatur peran tersebut. Yang itu sepenuhnya opsional dan plugin tidak memerlukannya untuk berfungsi.

Saya mencoba memahami bagaimana Anda mengambil peran - sepertinya MFA tidak diatur dalam kasus Anda, bukan? Sepertinya akun Anda dapat mengambil beberapa peran tanpa otorisasi tambahan? Apa kasus penggunaan untuk itu?

Kami tidak mengizinkan masuk atau mengambil peran apa pun tanpa MFA, sesuai dengan praktik terbaik AWS, jadi sangat ingin memahami kasus penggunaan di sini.

Oke jadi saya beralih ke peran, menggunakan skrip aar untuk memicu autentikasi MFA, dan kemudian beralih ke peran lain lagi. Tentu saja ini adalah kasus plugin AWS versi lama dan saya tidak mengetahui fitur-fiturnya yang lebih baru. Biarkan saya mengubah konfigurasi saya dan kembali ke ini.

Terima kasih, @robvadai ! Sementara itu, saya akan mencoba memikirkan kasus penggunaan seperti milik Anda.

Berdasarkan pesan kesalahan yang Anda berikan:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::11111111111:user/original_user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::9999999999999:role/myrole

user/original_user tidak memiliki hak untuk berasumsi role/myrole .

Melihat kode, perilakunya harus identik antara aar dan asp . Berikut adalah baris dari aar yang menurut Anda berhasil untuk Anda:

local credentials_output=$(aws sts assume-role --role-arn ${role_arn} --role-session-name ${session_name} --query '[Credentials.AccessKeyId,Credentials.SecretAccessKey,Credentials.SessionToken]' --output text | tr "\t" "\n")

Ini adalah baris dari asp yang, menurut Anda, gagal untuk Anda:

local assume_cmd=(aws sts assume-role "--profile=$profile" "--role-arn $role_arn" "--role-session-name "$profile"" "$mfa_opt" "$extid_opt")

Dalam kedua kasus:

  • role-arn akan sama
  • role-session-name akan berbeda dengan -session di akhir nama profil (dan itu sebenarnya tidak relevan)
  • mfa_opt dan extid_opt akan kosong

Jadi kedua perintah harus menjalankan perintah aktual yang sama.

Meskipun saya harus mengatakan, skrip memberi saya ide tentang cara menghilangkan jq sebagai ketergantungan agar asp berfungsi. Bagus.

Mengubah konfigurasi saya, diuji untuk satu profil dan berfungsi tanpa skrip aar !

Namun, ketika saya tidak mengetikkan durasi sesi, saya mendapatkan:

Please enter your MFA token for arn:aws:iam::1111111111:mfa/myuser:
123456
Please enter the session duration in seconds (900-43200; default: 3600, which is the default maximum for a role):

asp:31: command not found: sess_duration
Assuming role arn:aws:iam::11111111111111111:role/muyser using profile AAAAA
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help
aws: error: argument --duration-seconds: expected one argument
Switched to AWS Profile: AAAAA

Terima kasih telah mengonfirmasi dan senang itu berhasil! Saya akan memeriksa mengapa berperilaku seperti itu dengan durasi sesi untuk Anda. Idenya adalah jika Anda hanya menekan Enter tanpa memasukkan durasi sesi, nilai default AWS akan digunakan, karena variabel durasi sesi kosong.

Apakah Anda keberatan membagikan detail sistem tempat Anda menjalankannya? Secara khusus, OS apa itu dan versi zsh (shell itu sendiri) yang Anda jalankan? Terima kasih!

Ya semuanya baik-baik saja sekarang, hanya satu hal lagi: Saya membutuhkan [profile PROFILENAME] sehingga awalan profile dalam file config sedangkan file credentials tidak membutuhkannya. Java SDK juga mengeluhkan awalan ini - dapatkah Anda mengubah skrip sehingga kami tidak memerlukan awalan profile ?

@maksyms macOS 10.15.7 (19H2)
Versi ZSH zsh 5.7.1 (x86_64-apple-darwin19.0)

Ya semuanya baik-baik saja sekarang, hanya satu hal lagi: Saya membutuhkan [profile PROFILENAME] sehingga awalan profile dalam file config sedangkan file credentials tidak membutuhkannya. Java SDK juga mengeluhkan awalan ini - dapatkah Anda mengubah skrip sehingga kami tidak memerlukan awalan profile ?

Itu bukan saya - itu adalah AWS CLI standar rawa, bukan saya, yang menempatkan [profile PROFILENAME] dalam file konfigurasi, jadi tidak yakin bagaimana saya dapat membantu. asp mengharapkan hal yang sama.

Namun, ketika saya tidak mengetikkan durasi sesi, saya mendapatkan:

Saya mereproduksi ini. Ini adalah bug, @robvadai. Bisakah Anda melaporkannya sebagai satu dan menandai saya di laporan? Saya kemudian dapat melihat untuk memperbaikinya.

@wnkz

Saya tidak keberatan memiliki fungsi yang berbeda untuk MFA dan yang lainnya, tetapi saya tidak berpikir fungsi asp harus melampaui pengaturan variabel lingkungan dan harus tetap seperti itu karena alasan kompatibilitas.

Tidak begitu yakin tentang itu - tujuan asp adalah untuk mengganti profil, bukan untuk mengatur variabel lingkungan, bukan?

tetapi hanya memeriksa atribut role_arn tidak cukup untuk memicu peran asumsi "manual".

@wknz Mengapa Anda mengatakan itu? Bisakah Anda menyebutkan alasan lain untuk memiliki role_arn di konfigurasi profil Anda?

@maksyms Saya sangat bingung dengan pertanyaan Anda
Pernahkah Anda membaca https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html ?

role_arn + source_profile adalah pengaturan paling dasar untuk menggunakan peran dengan AWS CLI. Saya tidak sering menggunakannya tetapi dapat menangani MFA jika saya ingat dengan benar.
Dengan konfigurasi ini, AWS CLI secara otomatis mengambil peran yang dikonfigurasi di profil, menyimpan kredensial, dan memperbaruinya saat diperlukan.

Saat Anda menggunakan peran, AWS CLI menyimpan kredensial sementara secara lokal hingga masa berlakunya habis. Saat berikutnya Anda mencoba menggunakannya, AWS CLI mencoba memperbaruinya atas nama Anda.

Cara untuk memberitahu AWS CLI yang profil untuk penggunaan adalah melalui --profile bendera atau AWS_PROFILE variabel lingkungan.
IMHO, fungsi asp hanya digunakan untuk membuat daftar profil yang ada dan mengatur variabel lingkungan dengan mudah sehingga AWS CLI dapat melakukan sisa pekerjaan untuk Anda sebagaimana dimaksud .

Sekarang, dengan fungsi yang diperbarui, peran diasumsikan secara manual, kredensial disimpan dalam variabel lingkungan dan tidak pernah diperbarui. Selanjutnya, mengasumsikan peran langsung menyebabkan masalah dengan jenis konfigurasi lanjutan lainnya menggunakan credential_process atau AWS SSO dari CLI v2.

Saya benar-benar tidak ingin terdengar kasar tetapi perubahan ini hanya memberi saya masalah. Saya tidak benar-benar tahu apa yang membuat Anda melakukan ini dan ini mungkin kasus penggunaan yang sangat baik tetapi ini adalah perubahan yang melanggar bagi saya dan setidaknya harus diimplementasikan dalam fungsi baru tetapi tidak menggantikan yang sudah ada.

👋

@wnkz Terima kasih banyak atas tulisan Anda yang ekstensif.

Saya minta maaf Anda merasa perubahan memberi Anda masalah. Dilihat dari reaksi beberapa individu lain, perubahan itu sudah menyederhanakan alur kerja mereka - dan itu selain pengguna sekitar 30-an yang menggunakan perubahan ini sebelum digabungkan.

Alasan penerapan perubahan ini persis terkait dengan dokumentasi yang Anda kutip (https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html).

Tujuan asp adalah untuk mengaktifkan menjalankan AWS CLI dan banyak perintah lainnya (dalam kasus kami, kubectl dan turunannya, misalnya) dalam konteks profil tertentu, dengan asumsi peran tertentu, di semua atau setidaknya tanpa harus menentukan baris perintah yang panjang. Untuk kasus di mana MFA diberlakukan, tidak mungkin melakukannya dengan asp . Dengan pembaruan ini, dimungkinkan untuk melakukannya.

Contoh kasus penggunaan yang sangat spesifik adalah seperti ini:

  1. Saya pengguna AWS IAM maksyms di akun root AWS
  2. Saya tidak diizinkan menjalankan perintah apa pun di AWS CLI, selain mengambil peran tertentu
  3. Setelah saya mengambil peran (termasuk peran lintas-akun), saya dapat menjalankan perintah apa pun yang saya perlukan dalam konteks peran itu. Salah satu contohnya adalah kubectl

Berikut ilustrasinya:

image

Inilah yang terjadi di sini:

  1. Tidak ada peran yang diasumsikan, hanya profil yang disetel dengan menyetel variabel lingkungan AWS_PROFILE
  2. Beralih ke konteks K8 yang tepat
  3. Mencoba mendapatkan daftar pod - seperti yang Anda lihat, AWS CLI gagal mengambil peran
  4. Memanggil asp diperbarui untuk melakukan MFA dan mengambil peran alih-alih hanya mengatur variabel lingkungan AWS_PROFILE
  5. Berhasil membuat daftar pod
  6. Menghapus profil menggunakan asp (yang hanya menghapus variabel lingkungan!) dan menyetel AWS_PROFILE ke profil yang tepat lagi (yang Anda anjurkan)
  7. Gagal mendapatkan daftar pod, karena AWS CLI gagal mengambil peran

Saya harap ini menjelaskan masalah yang diselesaikan PR ini secara lebih rinci.

Sekarang kembali ke kasus penggunaan Anda.

Apa yang saya _tebak_ berdasarkan deskripsi Anda adalah bahwa cara Anda lebih suka menggunakan AWS CLI adalah dengan menentukan --profile setiap kali atau mengatur variabel lingkungan menggunakan "bodoh" asp dan kemudian memiliki AWS CLI mencari tahu sisanya. Seperti yang Anda lihat, kubectl , serta beberapa alat lain tidak berfungsi dalam situasi itu.

asp adalah cara untuk mengganti profil, bukan hanya mengatur variabel lingkungan.

Saya bertanya-tanya apa cara terbaik untuk membantu Anda. Adakah saran selain mengembalikan perubahan?

🙏 Harap pengelola, baca ini sebelum menggabungkan hal-hal lain di plugin ini.
@53jk1 @mcornella Saya menyebut Anda karena Anda meninjau dan menggabungkan PR sebelumnya.

Perubahan yang diperkenalkan oleh #8419 buruk karena beberapa alasan:

  • Ini adalah perubahan besar yang tidak diumumkan
  • Paling baik, tidak berguna karena "fungsi" ini seharusnya diterapkan di AWS SDK (dan karenanya AWS CLI) sendiri

@maksyms

Satu-satunya hal yang saya lihat dengan perubahan ini adalah bahwa alur kerja harian saya benar -
Saya sangat menghargai seseorang yang berkontribusi pada plugin ini tetapi ini adalah pengembangan perangkat lunak yang buruk.

Saya memahami masalah Anda dengan alat seperti kubectl ; hal serupa terjadi dengan terraform saat menggunakan MFA.
Tetapi sekali lagi, alat tersebut bertanggung jawab untuk menggunakan versi AWS SDK yang benar yang seharusnya membaca format konfigurasi umum dan secara otomatis mengambil peran menggunakan MFA atau tidak.

Fungsi asp hanya berfungsi untuk kasus penggunaan khusus Anda dan sepenuhnya mengabaikan alur kerja menggunakan alat yang berbeda (mis. aws-okta, aws-vault, ...).

Saya melihat ini karena saya memperbarui oh-my-zsh setiap hari tetapi saya dapat menjamin bahwa banyak pengguna AWS akan menjadi sangat marah segera setelah mereka memperbarui oh-my-zsh. Ini adalah satu-satunya perubahan yang membuat saya secara manual memutar kembali oh-my-zsh selama bertahun-tahun.

Saran saya untuk menemukan kompromi adalah:

  • kembalikan fungsi asp ke fungsi sebelumnya (apa yang Anda sebut bodoh)
  • ganti nama fungsi asp menjadi sesuatu yang baru seperti asp-mfa atau apa pun.

@wnkz Kebetulan Anda sedang berbicara dengan pengelola baru-baru ini.

  1. Tidak yakin bagaimana Anda membayangkan perubahan "diumumkan" pada perangkat lunak yang dikembangkan seperti ini? Akan baik untuk mendengar pikiran Anda.
  2. PR tersedia bagi siapa saja untuk mencari sekitar 1 tahun. Beberapa orang berkomentar. Tidak ada yang mengangkat masalah ini. Saya tidak mengatakan itu tidak penting - saya hanya mengatakan bahwa saya berjuang untuk melihat bagaimana lebih banyak umpan balik dapat dikumpulkan.
  3. Diberi pilihan untuk memperbarui _banyak_ alat "rusak" dan memperbarui satu plugin yang dapat mengatasinya, pendekatan mana yang lebih pragmatis?

Oke, biarkan aku memikirkan ini.

Satu pemikiran lagi: akankah memperkenalkan beberapa env var untuk menunjukkan apakah akan mengambil peran atau tidak sebagai pilihan?

Anda secara sewenang-wenang dinyatakan sebagai pengelola lima jam yang lalu, jadi harap tetap tenang dan singkirkan kartu "pengelola".
Kita semua manusia sedang berdiskusi tentang perangkat lunak. Saya minta maaf jika saya menyakiti perasaan Anda; tidak ada yang pribadi dalam komentar saya tentang perubahan yang Anda bawa.

1.

Nah, ini adalah praktik pengembangan dasar yang baik; Anda tidak tiba-tiba sepenuhnya mengganti perilaku alat/fungsi/metode tanpa memberi pengguna peringatan dan waktu yang tepat untuk beradaptasi atau menemukan solusi. Jika Anda sangat membutuhkan perubahan Anda, setidaknya tambahkan fungsi baru dengan nama baru tetapi jangan memaksa orang untuk menggunakan solusi Anda. Dalam pandangan saya, Anda baru saja memecahkan sesuatu yang bukan tanpa solusi tetapi mengembalikan ke versi sebelumnya. Saya tidak mengatakan ini tidak berguna untuk semua orang, tetapi mengatakan ini berguna untuk 30 tidak berarti itu untuk orang lain.

2.

Fakta bahwa PR #8419 dibuka lebih dari setahun yang lalu sama sekali tidak relevan. Bukan karena saya pengguna oh-my-zsh atau plugin ini sehingga saya harus melihat permintaan tarik oh-my-zsh. Saya tidak tahu berapa banyak OSS yang Anda gunakan, tetapi saya cukup yakin Anda tidak melihat setiap permintaan tarik yang dibuka di setiap repositori itu.

3.

Sekali lagi, Anda mencoba memperbaiki sesuatu yang tidak rusak. Tentu saja memaksa setiap alat pihak ketiga untuk menggunakan AWS SDK dengan benar akan sulit jika bukan tidak mungkin, tetapi itu adalah satu-satunya cara yang waras untuk melakukannya.

Sebagai kesimpulan, jika Anda baru saja menambahkan fungsi baru dengan nama baru dan memberi tahu semua orang yang memiliki masalah Anda untuk menggunakannya daripada asp kita tidak akan pernah melakukan diskusi ini ; masalah Anda masih akan terpecahkan dan alur kerja saya (dan salah satu dari banyak lainnya) tidak akan rusak.

Saya tidak berpikir saya akan menghabiskan lebih banyak waktu untuk membahas ini karena saya telah menyajikan sebagian besar argumen saya. Saat ini, plugin ini tidak berguna bagi saya jadi Anda akan melakukan sesuatu sebagai pengelola baru atau saya akan mengembalikan fungsionalitas asli di plugin lain.

Semoga harimu menyenangkan

@wnkz Anda benar, kami sedang mendiskusikan perangkat lunak, dan satu-satunya tujuan saya adalah membantu membuat fungsi ini lebih baik untuk komunitas, bukan hanya untuk Anda atau saya. Sebagian besar saran Anda tidak konstruktif dan tidak mungkin diterapkan dalam kasus khusus ini; nada Anda berbunyi agresif, pendekatannya terlihat idealis, dan perilakunya bersifat demagogik. Meskipun saya mengerti bahwa Anda kesal karena perubahan dalam kode sumber terbuka yang Anda tarik setiap hari merusak alur kerja Anda, itu tidak membenarkan perilaku beracun. Saya sarankan ini berhenti sekarang.

Sejauh ini, saya telah mencoba untuk fokus pada pemahaman dan perbaikan masalah spesifik yang Anda angkat, yang menghalangi alur kerja Anda, bukan pada nada percakapan ini. Satu saran konstruktif yang saya _memiliki_ dengar dari Anda adalah memperkenalkan fungsi dengan nama berbeda untuk mengambil peran. Oke, mungkin, karena komit ini belum lama keluar, ini adalah cara yang masuk akal. Saya akan menerapkannya sekarang.

Hai, yang di sana,

itu berfungsi dengan baik ketika saya menggunakan peran tetapi tidak meminta MFA untuk profil sumber lagi.

Saya menambahkan mfa_serial ke profil sumber saya.

Jadi profil sumber ini memiliki mfa_serial tetapi tidak role_arn dan source_profile jelas.

Ada ide?

Saya memperbaikinya tetapi kode memiliki beberapa duplikasi, perlu merapikannya: https://github.com/ohmyzsh/ohmyzsh/compare/master...robvadai :bugfix/aws-mfa-with-source?

Omong-omong, menghilangkan waktu masih menghasilkan kesalahan:

acp myprofile
Please enter your MFA token for arn:aws:iam::1111111111:mfa/myuser:
123456
Please enter the session duration in seconds (900-43200; default: 3600, which is the default maximum for a role):


An error occurred (AccessDenied) when calling the GetSessionToken operation: MultiFactorAuthentication failed, unable to validate MFA code.  Please verify your MFA serial number is valid and associated with this user.
Switched to AWS Profile: myprofile

@robvadai Bisakah Anda mencatatnya sebagai masalah terpisah dan membagikan konfigurasi dan kredensial Anda? Saya tidak yakin saya mengerti apa yang Anda maksud ketika Anda mengatakan "untuk profil sumber kami tidak memiliki role_arn" - saya juga tidak.

Alasan masalah kedua ketika Anda tidak menentukan durasi sekarang adalah karena otentikasi MFA gagal, bukan alasan lain - jadi itu tidak ada hubungannya dengan plugin.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

dogrizz picture dogrizz  ·  3Komentar

nimmoadam picture nimmoadam  ·  3Komentar

jaredmoody picture jaredmoody  ·  3Komentar

victorsenam picture victorsenam  ·  3Komentar

thienedits picture thienedits  ·  3Komentar