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.

FALLENANGEL: priznam se ze nejsem uplne fanda istia/servicemesh obecne, ale mozna (pravdepodobne :) mam jen malou predstavivost. Prijde mi to jako hodne tezkotonazni udelatko a nejak nevimkde bych to realne nasadil, nebo kde by ten zlomek features co od toho chci nepokryla nejaka potunena haproxy nebo nginx. Ma tu nekdo realny nasazeni, kde by se clovek bez istia vazne neobesel a nebo se bez nej obesel velmi tezko ?