Research:

Creación de políticas y permisos en AWS

Para administrar las características de políticas es necesario acceder a la sección de IAM de AWS.

Básicamente el uso de políticas permite gestionar las solicitudes de acceso hacia recursos dentro
de AWS, es decir, gestiona quién accede a que recursos validando si es que tiene o no tiene acceso
o permisos para realizar alguna acción.

Para comenzar contamos con 4 principales elementos: IAM, Cuenta Root(Cuenta main default
desde la cual se inicia la delegación de permisos), Users(Elementos usuario que interactúan con los
diferentes elementos de aws) y Groups(Contenedor de users).

Políticas: Las políticas se crean como una estructura en formato Json y definen los permisos,
preferentemente debe usarse el principio de privilegios minimos.

 Que es AWS IAM:

o Identity and Access Managment, Servicio web para controlar de manera
segura el acceso a servicios de AWS, puede administrar de forma
centralizada a los usuarios, las credenciales de seguridad y los permisos que
controlan a qué recursos y aplicaciones de AWS pueden obtener acceso.
  Usuarios:
o Es una entidad que se crea en AWS para representar a la persona o a la
aplicación que se utiliza para interactuar con AWS.
 Permiso:
o Es la acción que se le otorga a una Persona, Rol o Grupo para que pueda
realizar cierta acción específica sobre un recurso en AWS.
 Rol:
o Una identidad de IAM que se puede crear en una cuenta y que tiene
permisos específicos. Un rol de IAM tiene algunas similitudes con un
usuario de IAM. Los roles y los usuarios son identidades de AWS con
políticas de permisos que determinan lo que la identidad puede y no puede
hacer en AWS.
 Grupos:
o Es la forma simple de administrar a un conjunto de usuarios. Los grupos
permiten especificar permisos para varios usuarios, lo que puede facilitar la
administración de permisos.
 Políticas:
o Es un objeto de AWS que, cuando se asocia a una identidad o un recurso,
define sus permisos. AWS evalúa estas políticas cuando una entidad
principal de IAM (usuario o rol) realiza una solicitud. Los permisos en las
políticas determinan si la solicitud se permite o se deniega.
 ACL:
o Access Control List, se utiliza para controlar qué entidades principales de
otras cuentas pueden tener acceso al recurso al que la ACL está asociada.
Las ACL son similares a las políticas basadas en recursos, aunque son el
único tipo de política que no utiliza la estructura de los documentos de
política JSON. Las ACL son políticas de permisos para varias cuentas que
conceden permisos a la entidad principal especificada. Las ACL no pueden
conceder permisos a entidades dentro de una misma cuenta.

Aws recomienda no utilizar la root account para administar sino más bien, recomienda
Analizando código del allow-secret-access.ts
import yargs from 'yargs';
import {Generic} from "../utils/Generic";
import {IAMController} from "../controllers/IAMController";
import {ServiceConfiguration} from "../interfaces/ServiceConfiguration";
import {ServiceFactory} from "../services/ServiceFactory";
import {SecretsManagerController} from
"../controllers/SecretsManagerController";
import {KMSController} from "../controllers/KMSController";

const argv = yargs.options({

profile: {
alias: 'p',
choices: Generic.getAllProfiles(),
demand: true,
type: 'string'
},
role: {
alias: 'r',
demand: true,
type: 'string'
},
secrets: {
alias: 's',
demand: true,
type: 'array'
}
}).argv;

const profile = argv.profile;

const region = argv.region;
const role = argv.role;
const secrets = argv.secrets || [];
const config: ServiceConfiguration = {profile, region};
const accountData = ServiceFactory.getAccountData(config);

const controller = new IAMController(config);

controller.getService().getRolePolicy({
RoleName: role,
PolicyName: role
}).then(async data => {
const policyDocument =
Generic.getPolicyDocument(data.PolicyDocument);
const sid = 'secretAccess';
const referencePath = 'aws/reference/secretsmanager/';
const resources: string[] = [];
const secretsManagerController = new
SecretsManagerController(config);
const kmsController = new KMSController(config);

for (const secret of secrets) {

await secretsManagerController.getService().describeSecret({
SecretId: secret
}).then(async data => {
if (data.ARN) {
 const arn = data.ARN.substring(0,
data.ARN.lastIndexOf('-'));
resources.push(
`${arn}-*`,
`arn:aws:ssm:${controller.getRegion()}:$
{controller.getAccountConfig().id}:parameter/${referencePath}${secret}`
);
}

if (data.KmsKeyId) {
await kmsController.getService().describeKey({
KeyId: data.KmsKeyId
}).then(data => {
if (data.KeyMetadata && data.KeyMetadata.Arn)
if (!resources.includes(data.KeyMetadata.Arn))
resources.push(data.KeyMetadata.Arn);
}).catch(error => Generic.logError(error,
'describeKey'));
}
}).catch(error => Generic.logError(error, 'describeSecret'));
}

if (policyDocument.Statement) {
const statement = policyDocument.Statement.find(statement =>
statement.Sid === sid);

if (statement)
statement.Resource =
statement.Resource.concat(resources.filter(resource => !
statement.Resource.includes(resource)));
else {
policyDocument.Statement.push({
Sid: sid,
Effect: 'Allow',
Action: [
'ssm:GetParameter',
'kms:Decrypt',
'secretsManager:GetSecretValue'
],
Resource: resources
});
}
}

await controller.getService().putRolePolicy({
RoleName: role,
PolicyName: role,
PolicyDocument: JSON.stringify(policyDocument)
}).then(() => {
Generic.logMessage(`${role} now has access to ${secrets.join('
')}`);
}).catch(error => Generic.logError(error, 'putRolePolicy'));
}).catch(error => Generic.logError(error, 'getRolePolicy'));
JFROG

Como configurar un ambiente para Jfrog desde 0

Permisos, grupos, iniciar con todo limpio

Start

Primero crear repos:

Locales, remotos y virtuales, agregar respo, local, clic

ios cocoa, Android gradle, node npm, java Maven.

Ejemplo con gradle nomenclatura nomnre Project- ambiente

Y crear

Con eso tenemos repo local para Android

Ahora un remoto para Android

Nos da una url para buscar artefactos

Remote antes del ambiente en name

Siguiente

Esto de abajo, solo si tuviéramos proveedor

Pero no hacemos nada, más que crear.

Repositorio virtual ahora

palabra reléase

Aquí si haremos algo más

Que repositorios va aintegrar el repo virtual

Seleccionamos los dos y crear

Para coca pods, solo hay local y remoto

Para Maven ejemplo con superapp

Hasta ahí todo igual, pero se ocupa otro local, pero realmente nadie hace nada de promover de
snapshot a reléase

-snapshot o deja ver la nomenclatura: no sería así

Aca en Maven se crean dos locales, solo uno de remoto y dos virtuales (reléase y snapshot)

De momento lo trabajamos así, porque quizá después si creen snapshots no falle

Vamos a crear el remoto:

Crear y listo

Ahora virtuales:
Acá solo cargamos el de desarrollo y el remoto, el snapshot no

Ahora creamos uno nuevo virtual pero para los snapshots

Los locales llevan el snapshot antes del ambiente y los virtuales alreves

Tenemos esto:

La única particularidad la tienen java con el reléase y snapshots

Ahora para npm:

Psss ya es lo mismo

1 por ambiente(local, remote, virtual)

Asi ya tenemos repos para Android, java, npm, nos falta los de cocoa

Esos tienen su particularidad, solo locales y remotos, no hay virtuales, pero se crean igual.

Esa fue la cosa fácil, ahora vamos con lo pelada

Ya teninendo repos de superapp, hay que crear grupos para java, npm, ios, Android

Nos vanos a identity and acces, groups, add new group:

Meter a los users

Luego el de npm:

Luego Maven:

Luego el de cocoa:

Y ya tenemos todos:

Al agregar users, puede ser desde el group, o al crear el user.

ADD NEW USER

Y por ultimo se puede asignar a uno o más grupos
Y save.

Lo siguiente sería ver la parte de los permisos:

Permissions

New permisos
Agregamos los repos

Como armar los permisos:

2 permisos: 1 deploy otro lecura

A super app gradle
Ire os agregando de dev, qa y prod

solo los read

New permiso Super app- gradele-deploy

Solo se agrega el remote

El delete nunca se marca para devs.

Un grupo tienen permisos d electura y despliegue, de los repos gradle locales en este ejemplo.

Se ocupan permisos de Maven y npm, pero aún no se ocupan.

FALTAN 2 COSAS IMPORTANTES

Zeus-reader-dev y Zeus-deployer-dev, estos son dos usuarios que existen en Jenkins

El user y el permiso se llama igual, lo mismo del reader.

Nos falta crear e user y permiso para todos los futuros proyectos: superapp, upaxer, delivery

Nos vamos a users y los creamos

Contraseña: strog paswword, usamos otro extra, password-generator

32 caracteres

Que no me ponga carateres de abrir y cerrar []{}()

No metemos este user a ningún grupo, guardar la contraseña almacenada:

Ahora el useer deployer:

Esos datos los guardamos donde? Para que jale el pipe??

Luego nos vamos a permisos con los mismos nombres:

El permisos se arma de que recursos, quienes podrán acceder

Repositorios de dev, users, agregar kis repos commons son repos en donde todos comparten
librerías específicas agregar a todos los readers
Falta agregar esos users al codebuild y al secret.

Vamonos tendidos como vandidos

Vaaaa no svamos a superapp dev en aws para configurar el user

Codebuild y también abrimos secret

En est ebuild vamos a confoigurar las variables de entorno

En secrets esta el devOps

Seleccionamos el secret value, ahí están todos los secrets, los JFROG_

QUE Nos falta, agregar el JFROG

ESTOS DE ABAJKO PARA LOS REPOS:

IGUAL TODOS los resolve pero para superapp

Y justo después todos los de JFROG_INFRA, que son los de arriba.

Basados en los de infra.

Se agregaron también los snapshot

Finalmente queda así

Nos vamos a environment nos copiamos todo lo de JFROG_SUPERAPP

LO mismo que hicimos con el secret agregamos las 12 variables nuevas

Todas como secretmanager , estas son variables de entorno

Ahí esta la url donde estamos parados, en el clave valor se le agrega el devops: VALUE
Le damos update y codebuild ya esta preparado para poder hacer los deploys para JFROG, siempre
y cuando ellos hagan referencia a los users definidos en las variables de entorno.

Estas fueron las 12 variables

Esas variables también se configuran en Jenkins, ya dependerá de cada nodo, deberían quedar.

REPASO: COMO SUBIR LAYERS A JFROG

Jfrog artifactos, dependencias, librerías, frameworks van a vivir en esta plataforma que están
hechos en casa, para evitar la parte dónde se hace la descarga, instalación local del Jar y se hace el
npm package.

¿Qué es un layer AWS? Para evitar estar repitiendo fragmentos de código, un layer es cpodigo
existente que se atacha en tu lambda, es como si descragaramos una dependencia.

Esto puede aplicar para sdks de Android, librerías de npm, IOS, Maven Java.

La idea es que todo aquello que se vaya a reuilizar no se tengan que estar pasando el jar en cada
proyecto, para evitar eso, usaremos Jfrog, estando ahpi disponible para cualquier lambda. Los
contras de un Layer, solo puedes atachar 5 layers a una lambda. Aunque tu jar de tu lambda se
pasa del máximo 270Mb creo es lo máximo aceptado en una lambda.

¿Qué son los repositorios?

Primer pantalla entrando a JFroog

Se ven los repos, en la pantalla inicial, se tiene una opción search para buscar los packages. Es
mejor buscar por los artefactos o paquetes, en infra tenemos algunos que se han desplegado apra
desarrollo.

Del lado derecho se muestra veces que se ha desplegado, etc

Si le doy clic a uno, me muestra lo siguiente

Si entramos a cada versión podemos ver info de cada layer.

Ahora en la visat de los builds muestra tpodas las compilaciones que hemos hecho

Y si accedo a el
Me muestra dellaes, en la view anterior dónde entramos desde el repo me lleva al build.

Tenemos esos datos detallados.

El menú de artifacts es el que usaremos más seguido, acá me enseña los artifactos por repositorio
Y así tienen una vista más amplia de su repo:

Talntport tendrá un repo por tecnologpia, uno para mavebn, gradel, uno para, cocoapods,
Python(no existe de momemnto), npm, pero actualmente y habrá uno por cada ambiente,
talentport-Maven-{environment}

Tenemos 3 tipos de repo en Jfrog, local: aquí se despliegan librerías(base de datos, acceso a secret,
download files) librerías para trabajo interno no se puedan exponer al publico, virtual: une los
remostos con los locales, por ejemplo si tenemos 3 repos locales para talentport, que se quieren
tener separadospero al final se quieren usar los 3 locales, y además un remoto, así trabaja solo
como un repo, es decir los 3 locales más el remoto quedan en uno solo y finalmente el remoto:
espejo del repo provado o virtual que alguien nos proporciona, en Maven siempre van hacia el
repo central de maven, npm van a registri, cocoapods hacia github, dependencias de terceros de
internet.

Finalmente solo usaríamos el virtual en nuestro código.

¿Quién usa el local? R=codebuild, nadie más. Todo lo local debe ir por pipeline.

Crear un user

Descargar un repo
Vamos a trabajar todo que es releases, con el mismo repo

Trabajando con el repo asociado y para los snapshtots, teneos nuestro repo de snapshot,
praeciera que spn 4 pero al final solo serán 2
En el pom se referencia a esa librería, mvn package, o build o install y el archi este se añade

Si le damos en download nos descarga el xml.

Par npm es similar

Se hace configuración y se añaden en npmrc en home

Para garadle se va ala carpeta gradle, gradle.properties

Dependencias configuradas con su user.

Básicamente para todos ya nos genera la configuración

Para cocoapods
Y en nuestro pod file agreganmmos

Para IOS es diferente, no existen virtuales, solo locales y remotos, pero el proceso es similar.
Aunque acá se agregan locales y remotos.
Aquí se agregan repositorios remotos y locales.

¿Cómo GENERAR EL LAYER?

INFRA-CORE-AWS-UTILS se conecta a un secretmanager y nos descarga el valor, se genera una

instancia, y obtiene el parámetro
Mvn test y lo cala.

Lo que vamos a ver es la parte del build tal cual

Como en este ejempo

Solo cambia la ruta de salida ¿?

El template solo lleva 2 parameters

Luego va el buildspec

Nodejs es necesario para instalar el cliente jfrog

Y corre comandos, crea el cliente glogaal de jfrog, sig línea jfrogconfigure agrega nueva config,
variables de entorno de la maquina virtual de codebuild passwors y url que no sea interactiva la
configuración. Siguiente línea, cual será el repo de consultas, cualquiera que es gradele, npm
usamos los virtuales igual ya está configurado para no moverle nada, buscamos los artifactos
virtuales, donde se van a desplegar los cambios y d+onde se despliegan los repos de snapshots, lo
único que se cambia es la parte del user JFROG_{PROYECTO}, la url es la misma para todos los
proyects

Comandos para el depliegue de nuestro artifacto

Borra las dependencias con el mismo name y misma versión y luego ese podemos ver los datos en
el build_id en JFrog, debemos tener cuidado con el versionado semántico 2.0.0, no se podrán
sobreescribir versiones.

Si alguien la caga, les dirá que no tienen permisos de sobreescritura, luego vamos al repo local y
podríamos ver la nueva dependencia, lo siguiente es generar el output templeate que es el que
usará ecloudformation para desplegar
Que archivos ocupamos en cloudformation para desplegar el layer

Ahora vamos a ver esto en acción:

Sube los cambios

Se manda solicitud de pipeline, empieza a correr.

También hay una regla com.upax.infra

En al siguiente fase, debería cambiarse
Y ya queda en la versión 1

Eroores:
1.-

No autorizado, no existia el user.

Era por un secret:

No existia el user anterior, se inetntab accaeder desde las variables de entorno, pero el secret
tenia al user viejo en lugar del nuevo, solo lo actualizo

2.-
Rechazado el artifacto, porque excluye ciertas rutas, la lirería era com.infra solo debía recibir
com.upax.infra error de configuración solo se lo quitó

3.- intentaba acceder al repo release

Pero ese no existía.

En el scope provided no lo toma de las dependencias sino de los layers.

Ya un ws que implemente el layer:

¿Cómo CONSUMIR EL ARTIFACTO?

El jar se mete en la carpeta dist para generar el código de la lambda.

Configuración normal de template.yml

El resto normal como cualquier otro template.

Tomar como ejemplo el project infra-ws-aws

En la sección de arriba se muesta como encende la instancia, al final la cierro con exit.

Para esto debe estar encendida mi ovpn de Zeus-prod

Luego me logueo en Jenkins:

MRC:
Se le da en Ok

Y en la descripción se le debe cambiar el repo

En codecommit busca Zeus-ios-sdk-infra-login y vamos hacia configuración y se copia la
descripción hacia el otro proyecto

Ios builder la versión 2

Todo apuntando hacia Zeus

Carpeta dist y guardar ya se tienen el proyecto.

Luego nos vamos a crear el pipeline:

Nos vamos a codepipeline y le das en crear canalización, con el mismo nombre del proyecto.
Debe ser el arn rol devops

Configuración avcanzada
Ahora si siguiente

En proveedor de origen vanmos a buscar el repo del pipelien se queda con codecommit
Y predeterminadps

Aquí viene lo chido.

En el job se creo un job nuevo en Jenkins en provider

Ahí viene el name

Ese usamos en la etapa del pipe

Project name el mismo que el name del repo y el path lo sacamos de la url

Siguiente

Luego en provvedro de implementacionl al ser de ios se va hacia un bucket comilado

La clave del objeto:

mobile/ios/sdk/{nombre_objeto_pipeline}.tar.gz
Tar.gz, no confucnir con la imagen

Configuración adicional:

arn:aws:kms:us-east-1:197631145735:alias/devops

Public read y listo

Stages a generar y listo

Luego en el buil checar que no haya pedos con Jenkins

Nos dio un error

Checar en espacio de trabajo

Aquí debería haber un podscpect, quiere decir que no se han subido cambios hacia rama de dev,
Malko desplegó esos cambios nos pasamos al pipe para checar que pedo

Para ahorita que se redespliegue.

Ahí esta
En Jenkins en historia de tareas vemos si hay un nuevo build

Aquí en esta sección vemos

En log de consultas cada x segundos está buscando

La hira que nos muestra es la ec2 de jenkis o la utc de USA, NOS APARECE UNA DOCUMENTACION
Apara validar al darle click en el linbk de la fase 2

Nos deja cver que está vinculado correctamentes, nos dice que se logro compilar

Checando los logs en jenkisn

Entramos a JFROG y buscamos Zeus-cocoapods

Login 1.0.0

Y listo ya está ready para hacer los pipelines de ios

Y dice que simón.

¿ No entendí como funciona lo del @scope?

¿Qué pasa si alguien la caga y le pone los datos de otra cuenta al desplegar desde el build?