AWS CLI Profil ve Kimlik Doğrulama Yönetimi

Tarafındankomut
0 Comments

Günlük AWS işlerinde onlarca farklı hesap, role ve ortamla uğraşan biri olarak söyleyebilirim ki AWS CLI profil yönetimi, sysadmin hayatını ya cennete ya da cehenneme çevirebilir. Yanlış hesaba deployment yapmak, production ortamında test komutu çalıştırmak ya da credential’ların sürekli expire olmasıyla boğuşmak… Bunların hepsini yaşadım ve bu yazıda öğrendiklerimi aktaracağım. AWS CLI’ın profil ve kimlik doğrulama sistemini doğru kurduğunuzda hem güvenlik açısından hem de operasyonel verimlilik açısından ciddi kazanımlar elde ediyorsunuz.

AWS CLI Kurulum ve Temel Yapılandırma

AWS CLI v2’yi kullanıyor olmanız gerekiyor. Eğer hâlâ v1 ile çalışıyorsanız, geçiş zamanı geldi demektir. Kurulum oldukça basit:

# Linux için AWS CLI v2 kurulumu
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# Kurulumu doğrula
aws --version
# aws-cli/2.x.x Python/3.x.x Linux/x.x.x exe/x86_64.ubuntu.xx

Kurulumdan sonra ilk yapılandırma için aws configure komutu kullanılır. Ancak bu komut sadece default profili ayarlar ve çoğu zaman yeterli olmaz. Gerçek dünyada birden fazla AWS hesabı, farklı region’lar ve çeşitli IAM rolleriyle çalışmak zorundasınız.

AWS CLI, kimlik bilgilerini ve yapılandırma ayarlarını iki ayrı dosyada tutar:

  • ~/.aws/credentials: Access key ve secret key bilgilerini içerir
  • ~/.aws/config: Region, output format ve profil ayarlarını içerir

Bu iki dosyanın farkını anlamak önemli. Credentials dosyası hassas bilgileri barındırır ve izinlerinin 600 olması gerekir. Config dosyası ise profil davranışlarını tanımlar.

Profil Sistemi: Çoklu Hesap Yönetiminin Temeli

Varsayılan profil dışında yeni bir profil oluşturmak için --profile parametresini kullanırsınız:

# Yeni profil oluşturma
aws configure --profile production
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Default region name [None]: eu-west-1
# Default output format [None]: json

# Staging ortamı için ayrı profil
aws configure --profile staging
aws configure --profile development

Bu işlemlerin ardından credentials dosyanız şu şekilde görünür:

# ~/.aws/credentials içeriği
[default]
aws_access_key_id = AKIAIOSFODNN7DEFAULT
aws_secret_access_key = defaultsecretkey

[production]
aws_access_key_id = AKIAIOSFODNN7PROD
aws_secret_access_key = productionsecretkey

[staging]
aws_access_key_id = AKIAIOSFODNN7STAG
aws_secret_access_key = stagingsecretkey

Config dosyası ise şu yapıda olur:

# ~/.aws/config içeriği
[default]
region = us-east-1
output = json

[profile production]
region = eu-west-1
output = json
cli_pager =

[profile staging]
region = us-east-1
output = yaml

[profile development]
region = us-east-1
output = json

Dikkat edin: credentials dosyasında profil adı direkt [production] şeklinde yazılırken, config dosyasında [profile production] şeklinde profile öneki kullanılır. Bu küçük fark başlangıçta kafaları karıştırır.

Profil Kullanımı

# Belirli bir profille komut çalıştırma
aws s3 ls --profile production

# Ortam değişkeni ile profil belirleme
export AWS_PROFILE=staging
aws ec2 describe-instances

# Hangi kimlikle çalıştığını kontrol etme
aws sts get-caller-identity --profile production

sts get-caller-identity komutu altın değerinde. Hangi hesapta, hangi kullanıcıyla çalıştığınızı anında gösterir. Production’a dokunmadan önce mutlaka bu komutu çalıştırın.

IAM Role Assumption: En Güvenli Yaklaşım

Uzun ömürlü access key kullanmak güvenlik açısından kötü bir pratik. Bunun yerine IAM role assumption kullanmak çok daha güvenli bir yaklaşım. Özellikle cross-account erişimde bu yöntem hem zorunluluk hem de best practice haline gelir.

Cross-account role assumption için config dosyanıza şunu ekleyin:

# ~/.aws/config
[profile dev-account]
aws_access_key_id = AKIAIOSFODNN7BASE
aws_secret_access_key = basesecretkey
region = us-east-1

[profile production-role]
role_arn = arn:aws:iam::123456789012:role/ProductionAdminRole
source_profile = dev-account
region = eu-west-1
role_session_name = my-production-session
mfa_serial = arn:aws:iam::987654321098:mfa/kullanici.adi

Bu konfigürasyonla production hesabına erişmek için:

# Role assumption ile komut çalıştırma
aws s3 ls --profile production-role
# MFA token isteyecek: Enter MFA code for arn:aws:iam::987654321098:mfa/kullanici.adi:

# Assumed role bilgilerini görüntüleme
aws sts get-caller-identity --profile production-role

role_arn: Üstlenilecek rolün ARN’ı source_profile: Temel kimlik doğrulamanın yapılacağı profil role_session_name: Audit loglarında görünecek session adı mfa_serial: MFA cihazının ARN’ı, bu parametre varsa token sorulur duration_seconds: Session süresini saniye cinsinden belirler, varsayılan 3600

AWS SSO ile Modern Kimlik Doğrulama

Eğer organizasyonunuzda AWS IAM Identity Center (eski adıyla AWS SSO) kullanılıyorsa, bu entegrasyonu CLI’a dahil etmek hem güvenliği artırır hem de credential yönetimini kolaylaştırır.

# SSO oturumu yapılandırma
aws configure sso

# Sihirbaz şu soruları sorar:
# SSO session name: my-company-sso
# SSO start URL: https://my-company.awsapps.com/start
# SSO region: eu-central-1
# SSO registration scopes: sso:account:access

Yapılandırma tamamlandıktan sonra config dosyasına şuna benzer bir blok eklenir:

[profile MyCompany-Production]
sso_session = my-company-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = eu-west-1
output = json

[sso-session my-company-sso]
sso_start_url = https://my-company.awsapps.com/start
sso_region = eu-central-1
sso_registration_scopes = sso:account:access

Giriş yapmak için:

# SSO ile giriş
aws sso login --sso-session my-company-sso

# Tarayıcı açılır ve SSO onayı yapılır
# Successfully logged into Start URL: https://my-company.awsapps.com/start

# SSO profiliyle komut çalıştırma
aws s3 ls --profile MyCompany-Production

# Oturumu kapatma
aws sso logout

SSO token’ları varsayılan olarak 8 saat geçerlidir ve ~/.aws/sso/cache/ dizininde saklanır. Bu süre dolduğunda tekrar aws sso login komutu çalıştırmanız gerekir.

Ortam Değişkenleri ile Dinamik Yapılandırma

CI/CD pipeline’larında veya Docker container’larında profile dosyalarını taşımak pratik değil. Bu senaryolarda ortam değişkenleri kullanmak daha uygun:

# Temel kimlik bilgileri
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCY"
export AWS_DEFAULT_REGION="us-east-1"

# Session token (geçici kimlik bilgileri için)
export AWS_SESSION_TOKEN="AQoXnyc4lcK4w..."

# Profil seçimi
export AWS_PROFILE="production"

# Yapılandırma dosyası konumunu değiştirme
export AWS_CONFIG_FILE="/custom/path/aws/config"
export AWS_SHARED_CREDENTIALS_FILE="/custom/path/aws/credentials"

Ortam değişkenlerinin öncelik sırası önemli. AWS CLI şu sırayla kimlik bilgisi arar:

  • Komut satırı parametreleri
  • Ortam değişkenleri
  • AWS IAM Identity Center
  • Credentials dosyası
  • Container credentials
  • Instance profile credentials

Bu öncelik sırası bazen beklenmedik davranışlara yol açar. Özellikle EC2 instance üzerinde çalışırken hem instance role hem de credentials dosyası varsa, ortam değişkeni yoksa credentials dosyası öncelik alır.

Geçici Kimlik Bilgileri ve STS

Bazı senaryolarda programatik olarak geçici kimlik bilgisi almanız gerekir. Lambda’yı trigger eden bir script, pipeline’da cross-account işlem veya zaman sınırlı erişim gerektiren durumlar bunlara örnek verilebilir:

# STS ile geçici kimlik bilgisi alma
CREDENTIALS=$(aws sts assume-role 
  --role-arn "arn:aws:iam::123456789012:role/DeploymentRole" 
  --role-session-name "deployment-$(date +%Y%m%d%H%M%S)" 
  --duration-seconds 3600 
  --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' 
  --output text)

# Değerleri değişkenlere atama
export AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | awk '{print $1}')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | awk '{print $2}')
export AWS_SESSION_TOKEN=$(echo $CREDENTIALS | awk '{print $3}')

# Artık bu kimlikle çalışabilirsiniz
aws sts get-caller-identity

Bu yaklaşımı bir deployment script’ine entegre ettiğinizde, her çalışmada taze kimlik bilgileri alırsınız ve belirli bir süre sonra otomatik expire olur.

Profil Yönetimi için Pratik Script’ler

Günlük işlerde profil yönetimini kolaylaştıracak bazı script’ler yazalım. Önce hangi profillerin mevcut olduğunu listeleyen basit bir komut:

# Tüm profilleri listele
aws configure list-profiles

# Her profilin hangi hesaba bağlı olduğunu göster
for profile in $(aws configure list-profiles); do
  echo -n "Profile: $profile -> "
  aws sts get-caller-identity 
    --profile "$profile" 
    --query '[Account, Arn]' 
    --output text 2>/dev/null || echo "Erişim hatası"
done

Aktif profili hızlıca değiştirmek için .bashrc veya .zshrc dosyasına eklenebilecek bir fonksiyon:

# ~/.bashrc veya ~/.zshrc içine ekleyin
awsp() {
  if [ -z "$1" ]; then
    echo "Mevcut profil: ${AWS_PROFILE:-default}"
    echo "Tüm profiller:"
    aws configure list-profiles
    return
  fi
  export AWS_PROFILE="$1"
  echo "AWS profili değiştirildi: $1"
  aws sts get-caller-identity --query '[Account, UserId]' --output text
}

# Kullanım:
# awsp              -> Mevcut profili ve tüm profilleri gösterir
# awsp production   -> Production profiline geçer ve kimliği gösterir

MFA Zorunluluğu ve Otomasyonu

Güvenlik politikası gereği MFA zorunlu olan ortamlarda CLI kullanımı biraz daha karmaşıklaşır. Özellikle script’lerde MFA token’ı manuel girme zorunluluğu süreci yavaşlatır. Bunun için session yönetimi yapan bir yardımcı script kullanabilirsiniz:

#!/bin/bash
# mfa-login.sh - MFA ile AWS session oluşturma

PROFILE="${1:-default}"
MFA_SERIAL=$(aws configure get mfa_serial --profile "$PROFILE")
TOKEN_CODE="$2"

if [ -z "$TOKEN_CODE" ]; then
  read -p "MFA Token: " TOKEN_CODE
fi

# Geçici kimlik bilgisi al
CREDENTIALS=$(aws sts get-session-token 
  --serial-number "$MFA_SERIAL" 
  --token-code "$TOKEN_CODE" 
  --duration-seconds 43200 
  --profile "$PROFILE" 
  --output json)

if [ $? -ne 0 ]; then
  echo "MFA doğrulama başarısız!"
  exit 1
fi

# Credentials dosyasını güncelle
aws configure set aws_access_key_id 
  $(echo $CREDENTIALS | jq -r '.Credentials.AccessKeyId') 
  --profile "${PROFILE}-mfa"

aws configure set aws_secret_access_key 
  $(echo $CREDENTIALS | jq -r '.Credentials.SecretAccessKey') 
  --profile "${PROFILE}-mfa"

aws configure set aws_session_token 
  $(echo $CREDENTIALS | jq -r '.Credentials.SessionToken') 
  --profile "${PROFILE}-mfa"

echo "MFA session oluşturuldu. Profil: ${PROFILE}-mfa"
echo "Geçerlilik: 12 saat"
export AWS_PROFILE="${PROFILE}-mfa"

Güvenlik Best Practice’leri

Profil ve kimlik yönetimi söz konusu olduğunda güvenlik ihmal edilemez.

Dosya izinleri doğru ayarlanmalı. Credentials ve config dosyaları yalnızca sizin okuyabileceğiniz izinlerde olmalı:

chmod 600 ~/.aws/credentials
chmod 600 ~/.aws/config
ls -la ~/.aws/

Kullanılmayan access key’leri devre dışı bırakın. IAM konsolundan veya CLI üzerinden:

# Kullanıcının access key'lerini listele
aws iam list-access-keys --user-name kullanici.adi

# Eski key'i devre dışı bırak
aws iam update-access-key 
  --access-key-id AKIAIOSFODNN7OLD 
  --status Inactive 
  --user-name kullanici.adi

Credentials dosyasını versiyon kontrolüne eklemeyin. .gitignore dosyanıza mutlaka şunları ekleyin:

# .gitignore
.aws/
*.pem
*_rsa
credentials

Access key rotasyonu. Production ortamlarında access key’leri düzenli olarak rotate edin. Bunu hatırlatan bir cron job yazabilirsiniz:

# Crontab'a ekle - her Pazartesi sabah uyar
0 9 * * 1 aws iam list-access-keys --query 'AccessKeyMetadata[?CreateDate<`2024-01-01`]' --output text | mail -s "AWS Key Rotation Gerekiyor" [email protected]

AWS Vault ile Güvenli Kimlik Saklama

aws-vault aracı, AWS kimlik bilgilerini işletim sisteminin keychain’inde saklayan ve geçici kimlik bilgisi yöneten açık kaynak bir araç. Özellikle MFA gerektiren ortamlarda çok işe yarıyor:

# macOS
brew install --cask aws-vault

# Linux
wget https://github.com/99designs/aws-vault/releases/latest/download/aws-vault-linux-amd64
chmod +x aws-vault-linux-amd64
sudo mv aws-vault-linux-amd64 /usr/local/bin/aws-vault

# Profil ekleme (keychain'e kaydeder)
aws-vault add production
# Enter Access Key Id: AKIAIOSFODNN7EXAMPLE
# Enter Secret Access Key:

# Komut çalıştırma
aws-vault exec production -- aws s3 ls

# Subshell açma
aws-vault exec production -- $SHELL

aws-vault kullandığınızda credentials dosyasında access key saklanmaz, işletim sistemi keychain’i kullanılır. Bu ekstra güvenlik katmanı özellikle laptop’larda çalışırken önemli.

Sonuç

AWS CLI profil ve kimlik doğrulama yönetimi, görünürde basit bir konu gibi gözükse de üzerine ne kadar özen gösterirseniz o kadar az sorunla karşılaşırsınız. Yıllardır edindiğim deneyimle şunu söyleyebilirim: Bu konuda kurduğunuz disiplin, ileride yaşayabileceğiniz güvenlik olaylarını ve operasyonel aksaklıkları büyük ölçüde engeller.

Pratik özet olarak şunları önerebilirim: Her ortam için ayrı profil kullanın, mümkün olan her yerde IAM role assumption tercih edin, uzun ömürlü access key yerine geçici kimlik bilgisi kullanmayı alışkanlık edinin. AWS SSO altyapınız varsa CLI entegrasyonunu mutlaka yapın, çünkü bu hem güvenli hem de en az sürtüşmeli yaklaşım. Credentials dosyanızın izinlerini ve içeriğini düzenli kontrol edin. Ve her şeyden önce, bir komut çalıştırmadan önce aws sts get-caller-identity ile doğru hesapta olduğunuzu teyit edin. Bu basit alışkanlık, beni defalarca büyük hatalardan kurtardı.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir