SPIP: Adding work load identity to Spark on Kubernetes documents (supersedes Secret Management)

[Mich Talebzadeh <mi...@gmail.com>]

Hi,

I would like to propose that the current Secret Management
<https://spark.apache.org/docs/latest/running-on-kubernetes.html#secret-management>
in
Spark Kubernetes documentation to include the more secure credentials
Workload identity) for Spark to access Kubernetes services.


Both Google Cloud Kubernetes (GKE
<https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity>)
and Azure Kubernetes Servi
<https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview>ce
support Workload Identity.


Taking notes from Google Cloud "Workload Identity is the recommended way
for your workloads running on Google Kubernetes Engine (GKE) to access
Google Cloud services in a secure and manageable way."


Workload Identity replaces the need to use Metadata concealment. The
sensitive metadata protected by metadata concealment is also protected by
Workload Identity.


In the usual way we had secret management that had to be put on a
shared drive that nodes of K8s cluster could access it. Thi was normally on
Cloud Storage and exposed the following


kubectl create secret generic spark-sa  --namespace=spark
--from-file=./spark-sa.json


that spark-sa.json file contained the following:


{
  "type": "service_account",
  "project_id": "<PROJECT_ID>",
  "private_key_id": "7a0d67d19c5d74337792c2320d698085e99999",
  "private_key": "-----BEGIN PRIVATE
KEY-----\nMIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDTsqxsyqDP4ViY\nhO0y7INv+tr8pKEz630DOkjI/kzKfvYelzlrjZ+/EAkqOymCzIIF1LsRG8y//G3/\nzUGR2tcUKbeEaeaJJtG3tGJfCnEoApL3+jA7OvNEbJoeFsMgZ82cDXeZtYdmPdX0\nd1gwpb1yrzBckecsuG0yHs0biz9pwR7xvIPjEo26AcrFvQeOLY2P60UM40AED0F+\n23QtlsXBTjMaWih020fWNlVJSaA+FkVGfSMgQ233/5qeVeLOIBJ9BDgxf4M9OYZO\n

.............................................

PRIVATE KEY-----\n",
  "client_email": "spark-bq@<PROJECT_ID>.iam.gserviceaccount.com",
  "client_id": "1003247655233199999999",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs
",
  "client_x509_cert_url": "
https://www.googleapis.com/robot/v1/metadata/x509/spark-bq%<PROJECT_ID>.
iam.gserviceaccount.com"
}


Cloud service account keys do not expire and require manual rotation.
Exporting service account keys has the potential to expand the scope of a
security breach if it goes undetected. If an exported key is stolen, an
attacker can use it to authenticate as that service account until noticed
and manually the key is revoked.That has a lot of stuff that could be read
on the mount directory.


Let me know your thoughts


   view my Linkedin profile
<https://www.linkedin.com/in/mich-talebzadeh-ph-d-5205b2/>


 https://en.everybodywiki.com/Mich_Talebzadeh



*Disclaimer:* Use it at your own risk. Any and all responsibility for any
loss, damage or destruction of data or any other property which may arise
from relying on this email's technical content is explicitly disclaimed.
The author will in no case be liable for any monetary damages arising from
such loss, damage or destruction.