DWICH: aha, v tom muze bejt rozdil no... zajimava cloudova politika

SADY: Na to jsem narazil, kdyz jsem vcera hledal ty tokens a to podle vseho nabizi Bitbucket jen v server verzi, ne jeho cloud verze.

Kdyz jsem to chtel najit pro Bitbucket cloud, tak jsem se dostal sem, kde pisou, ze to v cloud verzi neni
Personal Access Token for Bitbucket Cloud?
https://community.atlassian.com/t5/Bitbucket-questions/Personal-Access-Token-for-Bitbucket-Cloud/qaq-p/677663

Mozna neco prehlizim.

BESH: Build args predavam, pro secrets me to nenapadlo, dalsi dobrej tip, dikes!

DWICH: proste personal token, kde ta persona je robot co ti buildi appku, tam si expiration nastavis sam

Personal access tokens | Bitbucket Data Center and Server 7.16 | Atlassian Documentation
https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html

Díky všem za rady! Ten ssh klíč je jednoúčelovej, čistě pro čtení z toho repo a na nic dalšího se nepoužívá. Namountovat ho mě nenapadlo, díky za tip.

S multistage počítám. Nicméně i když půjde o multistage, tak stejně neodpadne ta nutnost dostat ze secret managera ten klíč do image, ať už přes COPY nebo mount. Je to tak?

Ten balíček z Bitbucketu potřebuju přidat v poslední fázi instalace aplikace (tzn. v posledním kroku multistage). Z toho mi vychází, že bych za tímhle posledním krokem měl udělat ještě jeden opravdu-poslední krok, do kterého přenesu sakum-prdum instalovanou appku (tzn. nezkopíruje se klíč). Je to tak?

DWICH: obecne nevidim problem mit nekde ssh klic, problem vidim v tom co s tim ssh klicem muzes delat. Jinymi slovy spis zalezi na tom jak silna prava jsou prirazena entite, ktera se autentizuje pomoci toho klice. Totez plati i o tokenu. Navic je ímho v tomhle pripade bezpecnejsi ssh klic nez token, kterej muze obsahovat spoustu readable informaci, ale asi bude zaelzet i na tokenu.

Zaznel tu i termin “secret” v kubernetes. Secret neni zas tak secret :) protoze je to pouze zakodovana nejaka imformace (klic, cert, heslo atd) v base64 - nic vic nic min. Pokud chces nejakou vyssi formu bezpecnosti, pak je na zvazeni treba nejakej vault, otazka je jak potom dostat automaticky data z toho vaultu.

Osobne bych sel cestou multistage jak Ti radi King

DWICH: ja prave nevim jak v bitbucketu - to prostredi nepouzivam a nemam rad.

JON: Na to jsem nenarazil a klidně si nechám napovědět. Co jsem v rychlosti prošel, tak mi vyskočilo tohle
Use OAuth on Bitbucket Cloud | Bitbucket Cloud | Atlassian Support
https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/
kde access token má platnost dvě hodiny a novej získáš přes OAuth2

Uložit v secret manageru ssh klíč nebo credentials pro získání access tokenu a jeho následný použití mi přijde podobný, možná trochu složitější s tím tokenem. Nebo mi něco uniká?


RAGNAROK: Díky za tip, nemám vyzkoušeno, mrknu na to.

.netrc file

DANIELSOFT, KING: Obojí mám vyzkoušený, tak snad cílovej setup nebude složitější. Build bude probíhat v GCP v Cloud Buildu, tak to zkusím napojit na tamní secrets (ne na kube secrets).

Díky!

DWICH: v Kubernetes je něco, co se jmenuje "secrets" a je přesně k tomuto: detaily si nepamatuju, protože jsem na tom dělal v roce 2016. možná je něco podobného v Compose či menším orchestrátoru, pokud je Kubernetes overkill, ale můžeš se u nich podívat, jak to mají udělané

Zdravíčko vespolek. Mám Dockerfile, v něm pouštím pip install -r requirements.txt a v něm je jeden balíček, co je na na Bitbucketu. pip si zavolá git, ten udělá git clone a balíček nainstaluje. Potud OK. Ten git ale potřebuje ssh klíč, aby se mohl Bitbucketu ověřit.

Ten ssh klíč můžu do Dockerfile zapsat, nechat proběhnout instalaci a pak ho smazat. Abych ten klíč do dostal do Dockeru, mám COPY, jenže to COPY může číst jen v rámci adresářů, kam může Dockerfile. A tím se dostávám k problému - kde by ten ssh klíč měl být uložený? Resp. jaké máte best practices, jak instalovat balíčky z privátních repos do dockerů?

Diky za feedback, kritiku snesu :)

ADMIX: Hele myslim ze zakos pro kyeryho makam nema uplne nejmensi prostredi (stovky nodu v clusteru, mrte service apod), a stejne nemam pocit ze bychom istio nebo treba linkerd potrebovali. Tak by me zajimal konrektni case kdy to cloveku muze pomoct.


FALLENANGEL: Jo ja ma stejnej pocit. To end2end sifrovani chapu, jen bych se to imho snazil resit asi jinak - ale ok tady to smysl asi dava.

VELDRANE: Nejsem si jistej, do jaky miry to zakaznici opravdu potrebuji a do jaky miry si opravdu chteji jenom hrat s novou technologii :) Cast z nich nasazuje Istio kvuli bezpecnosti, protoze s jeho pomoci muzes snadno a ve velkym rozsahu nasadit pod to pod sifrovani.